interessante lettura, utile per approfondire alcuni concetti (Yomgui)
(sta facento un confronto tra USB2.0 e FIREWIRE 400) :
// Well, final speed depends on many parameters, and not only physicals ones.
For examples, do a copy of a big files (likes more 100MB), using ambient and an hd enclosure with both connectic: USB2.0/FW400.
Do it from the HD to the RAM (a Read so) and do it again in the opposite way (a Write).
Then do the same process but use the shell command 'Copy' with parameter 'buf=2048'.
In this process with have not changed any physicals parameters, only a software one: the amount of data to transport per SCSI command.
USB and FW uses stricly the same SCSI command to operate read/write actions.
Now in USB data comming from the USB bridge are copied by the CPU at the place requested by the application.
In FW, incoming data are copied into this memory place by a DMA unit.
So now think about this: the CPU copy is slow specially when data are not "well presented" (bad alignements, not in cache, ...), and indeed the CPU is busy to this task.
The DMA copy is fast because the DMA is dedicated to this copy task.
At the end of the copy we only have to indicate to the CPU data cache the full area to mark as trashed to be sure that a cached read is sync.
But there is a pb with the DMA: it needs to be programmed. And this program is a block of memory prepared by the CPU.
The USB doesn't have such software overhead.
So you see that the USB may be faster if the FW stack is too slow to program the DMA and if requested data transfer is also too small to benefit of the DMA copy.
Actually, I've not given many time to see how fast and efficient is my Helios DMA programming code.
So if we're in the cross point where block is too small, the USB 2.0 transfer may be as fast or faster than FW.
That's why I request you to use the buf= parameter of Copy to increase this per command buffer size.
And finally, I've also seen on internet that some FW bridge are badly designed and are slower than the USB one to communicate to the ATA bridge, the one that effectively drives the HD.
For information: with my setup, I've reached a max of 25 MegaByte/s on a read transfer to RAM: using copy and buf=2048 (that gives 1MB buffer as buf uses HD block size unit = 512 bytes in most cases).
Someone else, using a FW800 plug, but connected to a FW400 hd enclosure (anyway Helios limits to S400 the max speed, as it doesn't support higher speeds configurations) has reach the speed of 40MB/s!
You see speed is an highly undefined thing.
Note2:
An SBP2 transfer of data is defined by sending an ORB command. This command transport the SCSI cmd data and a pointer to a scatter-gather (SG) table to define where wanted data need to be put by the DMA.
Each entry of the SG table limits the size of described memory area by the number of bits to indicate this block size: 16bits here, so a theorical maximum of 65535 bytes. But for DMA performance and alignement compliance, I've limited it to 65532 bytes (to be aligned on 4 bytes).
So using a 1MB data transfer needs filling: 1*1024*1024/65532 ~= 17 entries. Each entry is 8 bytes long => 136 bytes of write overhead compared to the USB.
// But anyway, I really need to profile my code to see where the bottleneck is.
I've got a MiniMax, and transfering 700MB to RAM using Ambient copy, leads me to 21MB/s in best case. Using USB2.0 gives 23MB/s in best case.
Even if Ambient copy process sends SCSI requests with 256KB buffers, I've found this FW limitation strange. That's why I really need to profile my code.
