I'm guessing from the path in the error message that this is a Unix/Linux system (MSWindows handles the timeout very differently).
While bandwidth (and latency!) has a big impact on the time taken to process the request, the PHP clock only starts when the PHP interpreter is invoked - this won't be until the webserver has received a complete request - i.e. the PHP execution time and hence the timeout should have nothing to do with how long it took for the webserver to process the request.
There is a timeout in PHP to determine how long it should spend receiving data from the webserver - max_input_time - and it has been reported that when this is exceeded it reports max_execution_time exceeded!.
So....assuming a 0 latency network...
00:00 user starts upload, apache timeout clock starts (but will keep getting reset by new packets arriving)
00:10 receiving of request completed by Apache, request handed over to PHP, max_input_time clock started
00:11 PHP has read all the input, max_input_time clock is stopped, max_execution_time clock started, script is executed
Now since on a Unix box, the max_execution clock only ticks when the PHP is executing, the problem is with PHP's performance / the performance of the PHP script.
Yes, you can increase the max execution time without it having a big impact elsewhere (although setting it via ini_set() / set_time_limit() on a script by script basis is neater than a global setting). But do make sure you're using an opcode cache, and if the php script is trying to parse the data, do beware of data / parser issues.