I regularly do Gbit network transfers with 40MB/s or better speeds without seeing any breaks longer than tenths of seconds. The low speed is because one of the machines refuses to send jumo-frames of a size supported by my switch.

I regularly do USB 2.0 transfers to or from external disks averaging 20MB/s or better without seeing any breaks longer than tenths of seconds. The lousy speed is because of a bad USB chip in the external USB enclosure.

I regularly do FW400 transfers to or from external disks averaging 40MB/s or better without seeing any breaks longer than tenths of seconds.

If you can survive these tenths of seconds of short pauses, then any PC built the last 5-10 years can handle 10Mbit/s continuous transfers directly to disk or into an user-space application. And with any I do include low-end Mini-ITX machines with three-digit clock speeds and tiny processor caches.

If you see 30 second transfer breaks, then you somewhere in your system have bad hardware or a bad driver that for some reason interferes with the rest of the kernel operation. I have seen this behaviour on several computers when an optical disk has problems reading sectors, or when a long (or bad) IDE cable results in transfer errors. The Windows kernel may then stop all other actions except maybe moving the mouse cursor while waiting for a timeout or for a correct read/transfer.

I have developed alarm server software that runs 24x7x365 on hundreds, if not thousands, of Windows machines and interfaces with external hardware requiring constant sub-second reactions. In this case the interface is RS232, but the systems would generate spurious alarms/alarm resets even for delays shorter than a second. These spurious alarms do not happen, because the machines do not get any lapses in the transfers. The machines are often connected in client/server groups where a number of client machines uses Ethernet to share the access to a common database and the external hardware. There are no problems with any lapses in the network traffic either, and all clients are runnning quite fast supervision polling with the server. Any hickup and the clients would immediately notice that the server machine isn't responding.

Yor data stream would represent a couple of percent of USB 2.0, 100TX or IDE disk transfer rates, so your transfer does not represent any load. Maybe you should try and deactivate as much hardware as possible can and see if you can figure out exactly what device that is causing your lockups. Or try with different PC hardware in case you are unlucky and have one or more PC where the manufacturer have never released acceptable drivers for some device. Writing device drivers for Windows isn't exactly fun, and this is reflected in the often quite lousy quality of much drivers. We normally knows this as the blue-screen-of-death, but lousy drivers can have quite a number of other side effects.

In the end, you should not need a middle store for a full burst, and any PC interface with 20Mbit/s or faster transfer capacity should be acceptable as long as you somewhere have the capability to buffer a couple of tenths of a second of the transfer. If you consume one or two seconds of buffer space then the buffer isn't too small. It is the PC that should be sent to service. 3D graphcis cards and 5.1 sound cards may be suitable for games. But they have in no way decreased the capability of a PC. A modern PC may not seem faster than a 10-year-old machine, because of M$ and some choices of developemnt tools. But open the control panel and remove all graphical extras that M$ likes to add, like transparent windows and slowly expanding menues and windows and you will notice that the windowing performance will suddenly be lightning fast. If you then thow away all applications that are running in emulated environments or interpreted code and throw away 50% of the services and the tools that likes to show up in the toolbar and any recent machine will suddenly become a screamer.