Gaming What happens if you download faster than your harddrive write speed?

[Zetta_x]

Anyone know? Will they slow the download speed or will you lose packets?

 

[yusuo]

Its impossible, it will slow down. Hence why uTorrent goes into Disk Overload, thats basically it downloading faster than the HDD write speed, and when it does hit Disk Overload it slow right down to basically nothing. Thats so it can write what is waiting to be written

 

[Zetta_x]

Its impossible, it will slow down. Hence why uTorrent goes into Disk Overload, thats basically it downloading faster than the HDD write speed, and when it does hit Disk Overload it slow right down to basically nothing. Thats so it can write what is waiting to be written

Lets say it was possible, what would happen? For example, I managed to destroy the intelligence of uTorrent's Disc Overload.

 

[raulpica]

Stuff gets buffered, and as soon as your PC's buffer gets full, everything will slow down and start going to crap.

If the program's smart enough (and uTorrent is) it'll automatically limit the MaxTransfer value to something that your HD can substain without stuffing the rest of your PC.

Back in DOS (maybe also Windows 9x) I'm sure that'd have caused a Bluescreen

 

[Zetta_x]

Thanks =D

With google pushing towards 1gigbit/sec speed, I realized that's faster than some standard mechanical drives. But thinking about it, data is being sent to you at a fast rate, there must been some probability of accidentally pushing too much.

 

[Chaosruler]

that's impossible, the ethernet and the PCI transfer speed are directed at the southbridge after the memory recycle meaning that the HDD gets a priority in the hardware level for file transfer speed, a file\packet can't be faster to transfer from PCI\ethernet to southbridge and to HDD than HDD recycle to itself, it's like assuming it's possible to drive from point city A (far west) to city B (far east) faster than city B to drive and return to itself from the middle city (city C for example)...

edit: just read your post...
I will put it simple, your motherboard brand would be a bloody fool to let something this idiotic happen, there's an HDD controller and there's a network card controller, one would be a fool to let the network technology exceed by so much the HDD technology on the same motherboard, what does it have to do with? even if your ISP provided you petabyte per second of bandwith, the so much you can get is limited by your network card, your network card transfer speed can't be of a faster technology then HDD's if the motherboard brand is smarter than a dunk, unless of course you are going to use an IDE or previous technology of the HDD itself, which even than it limits the sourthbridge and the northbridge together and won't let you use the full bandwith that even the network card allows due to buffer being charged, in that case your PC will end up slowing as hell while writing that data and stopping all network communication (meaning it will only write the data it has to write + saved data that it couldn't write in time and won't allow more data to be downloaded until it's done)

 

[Fishaman P]

Thanks =D

With google pushing towards 1gigbit/sec speed, I realized that's faster than some standard mechanical drives. But thinking about it, data is being sent to you at a fast rate, there must been some probability of accidentally pushing too much.

Then the data is written to RAM and put in a queue.
If that queue is filled, I'd imagine the PC would freeze due to
A) Being out of RAM
B) Trying to access the pagefile when the disk is already under max load

 

[raulpica]

that's impossible, the ethernet and the PCI transfer speed are directed at the southbridge after the memory recycle meaning that the HDD gets a priority in the hardware level for file transfer speed, a filepacket can't be faster to transfer from PCIethernet to southbridge and to HDD than HDD recycle to itself, it's like assuming it's possible to drive from point city A (far west) to city B (far east) faster than city B to drive and return to itself from the middle city (city C for example)...

edit: just read your post...
I will put it simple, your motherboard brand would be a bloody fool to let something this idiotic happen, there's an HDD controller and there's a network card controller, one would be a fool to let the network technology exceed by so much the HDD technology on the same motherboard, what does it have to do with? even if your ISP provided you petabyte per second of bandwith, the so much you can get is limited by your network card, your network card transfer speed can't be of a faster technology then HDD's if the motherboard brand is smarter than a dunk, unless of course you are going to use an IDE or previous technology of the HDD itself, which even than it limits the sourthbridge and the northbridge together and won't let you use the full bandwith that even the network card allows due to buffer being charged, in that case your PC will end up slowing as hell while writing that data and stopping all network communication (meaning it will only write the data it has to write + saved data that it couldn't write in time and won't allow more data to be downloaded until it's done)

I thought that he meant a theorical scenario where there aren't any bottlenecks during the entire track. Also, I'm sure that a modern SB (now called PCH) with a PCIe GB Ethernet wouldn't have any problems in doing all that on a DMI 2.0 bus.

LOL, you edited your post while I was writing. Yes, indeed the buffer full scenario was what I had written a few posts earlier.

EDIT: The problem is that you can't REALLY download more than 250MB/s with the current Internetz speeds! (mechanical write limit) But there wouldn't be any problems for the rest of the hardware to support that to the HD.

Instead, let's drop the Ethernet entirely, and talk about transferring from a PCIe SSD (obscenly high read speed) to a mechanical HD. In that case you'd cap the writing limit, and it'd just stop at 250MB/s, while things get buffered and sent only when there's free space in the buffer. But I'm sure that there wouldn't be any chipset-driven bottlenecks.

 

[BORTZ]

The program would probably crash, return and error, stop Utorrent or something, or cause significant damage to your data on your harddisk.

 

[FAST6191]

Hmm I guess it is fast enough to worry something even if I take protocol overhead and network overhead (little home routers might claim gbit but damned if I have seen one do it properly). I reckon on top of that the hash calculations would probably make it CPU bound and Windows and utorrent would be able to handle it but I will say most of us have enough RAM to be a worthwhile ram disk.

On top of that if you are feeling like a tart
http://www.amazon.com/Gigabyte-GC-RAMDISK-i-RAM-Hard-Drive/dp/B000EPM9NC/

 

[Chaosruler]

that's impossible, the ethernet and the PCI transfer speed are directed at the southbridge after the memory recycle meaning that the HDD gets a priority in the hardware level for file transfer speed, a filepacket can't be faster to transfer from PCIethernet to southbridge and to HDD than HDD recycle to itself, it's like assuming it's possible to drive from point city A (far west) to city B (far east) faster than city B to drive and return to itself from the middle city (city C for example)...

edit: just read your post...
I will put it simple, your motherboard brand would be a bloody fool to let something this idiotic happen, there's an HDD controller and there's a network card controller, one would be a fool to let the network technology exceed by so much the HDD technology on the same motherboard, what does it have to do with? even if your ISP provided you petabyte per second of bandwith, the so much you can get is limited by your network card, your network card transfer speed can't be of a faster technology then HDD's if the motherboard brand is smarter than a dunk, unless of course you are going to use an IDE or previous technology of the HDD itself, which even than it limits the sourthbridge and the northbridge together and won't let you use the full bandwith that even the network card allows due to buffer being charged, in that case your PC will end up slowing as hell while writing that data and stopping all network communication (meaning it will only write the data it has to write + saved data that it couldn't write in time and won't allow more data to be downloaded until it's done)

I thought that he meant a theorical scenario where there aren't any bottlenecks during the entire track. Also, I'm sure that a modern SB (now called PCH) with a PCIe GB Ethernet wouldn't have any problems in doing all that on a DMI 2.0 bus.

LOL, you edited your post while I was writing. Yes, indeed the buffer full scenario was what I had written a few posts earlier.

if we assume out bottlenecks it'll be the same question as "what happens if my gas in my car won't reach the carburetor [a pot in the car that mixes gas and air for the engine] in time for the mixture?" the answer will be simple : it won't reach the engine in time, the engine won't manage to ignite it and pure energy won't be made, meaning your engine will lack power for a second, that's where the alternator kicks in for a second try, if the second recycle won't be the in time your car's turned off because the engine can't do much more which leaves your car immobile, but the car is DESIGNED so the carburetor will get both gas and air in time, any malfunction there is an ISSUE in car itself

DMI is a highway between NB and SB, that's it, until the network bus reachs either it needs to wait for the next recycle or to time itself to take it's recycle faster than the HDD unit, however until it reachs the NB for transfer speed use, it needs to wait for the memory to complete it's cycle which is timed for the processor mostly to steal some of it's L3 cache, meaning it will be a poor driver coding to overbuff the memory from the DMI together with L3, it's creating a mess out of a problem, of course you can direct the network bus directly to the SB - you than you have no winning here over DMI II, even if it offers double lane similar to PCI-E to get 40gb\s bandwith, also you have to remember that DMI II is a highway designed per timing, meaning that it can't be made 20GB just for network speed, it gotta transfer EVERYTHING it got on it's trucks, even the buffer

 

[raulpica]

DMI is a highway between NB and SB, that's it, until the network bus reachs either it needs to wait for the next recycle or to time itself to take it's recycle faster than the HDD unit, however until it reachs the NB for transfer speed use, it needs to wait for the memory to complete it's cycle which is timed for the processor mostly to steal some of it's L3 cache, meaning it will be a poor driver coding to overbuff the memory from the DMI together with L3, it's creating a mess out of a problem, of course you can direct the network bus directly to the SB - you than you have no winning here over DMI II, even if it offers double lane similar to PCI-E to get 40gbs bandwith, also you have to remember that DMI II is a highway designed per timing, meaning that it can't be made 20GB just for network speed, it gotta transfer EVERYTHING it got on it's trucks, even the buffer

Indeed, but don't think of 20GBs, 250MB/s would be enough to saturate the drive's writing speed. 20GB is overkill

Also, NB and SB are now integrated on a single die (PCH), I guess that access times between them are now pratically non-existant.

 

[funem]

Its the same as copying from a fast source to a slow target, the buffer will fill then it will stop reading from the source until there was sufficient resources for it to continue. Its like trying to copy from a SATA drive to a very slow IDE drive, your PC will not blow up and information wold not be lost, it would just simply stop asking for source data until it had written out some of the buffered information.

 

[Chaosruler]

DMI is a highway between NB and SB, that's it, until the network bus reachs either it needs to wait for the next recycle or to time itself to take it's recycle faster than the HDD unit, however until it reachs the NB for transfer speed use, it needs to wait for the memory to complete it's cycle which is timed for the processor mostly to steal some of it's L3 cache, meaning it will be a poor driver coding to overbuff the memory from the DMI together with L3, it's creating a mess out of a problem, of course you can direct the network bus directly to the SB - you than you have no winning here over DMI II, even if it offers double lane similar to PCI-E to get 40gbs bandwith, also you have to remember that DMI II is a highway designed per timing, meaning that it can't be made 20GB just for network speed, it gotta transfer EVERYTHING it got on it's trucks, even the buffer

Indeed, but don't think of 20GBs, 250MB/s would be enough to saturate the drive's writing speed. 20GB is overkill

Also, NB and SB are now integrated on a single die (PCH), I guess that access times between them are now pratically non-existant.

the PCH and it's supportive mobo's and CPU's are simply cutting the NB and giving the roles to the CPU (memory controller etc) and SB (which is now called PCH, but still it's a southbridge buffed with extra abilities), it's still timed and recycles with timing, it's just done on the processor and buffed to the memory (and incase it's flagged, the L1 cache of the processor), that's why DMI was done for the PCH era mobos (Intel), to communicate with the virtual northbridge that the processor has (memory controller - buffing) and the rest of the packets that needs to be saved on the HDD are sent from the PCH to the SATA controller\IDE controller depended on who's your master HDD controller (even if the slave is aimed as target, it gotta pass from master), it's enough recycles and shit to time the network packets to be slower than DATA to DATA cables just to transfer from controller\port to another controller\port, especially if it's itself, though if you copy data from SSD drive to SATA II drive, the results are obvious, also only 1 lane is preserved for buffing, that's to prevent freezing, it's a command processed due to the SSD coding and it's done in order to prevent buffer overload done by the SSD because they are a zillion-times faster than SATA II\III HDD (talking about the mechanical ones here, obviously), it's also why Intel invented an emulator between two ports to combine their transfer speed with simple priority remapping