Quote:

Actually, USB iso transfers were implemented before we switched to the unified pciusb drivers. Some of the seperate UHCI/OHCI/EHCI drivers (at least the Pegasos UHCI) had it.
I couldn't care less to add it to pciusb , though ....

Yomgui

Ah allright excellent news! Good job. the data loss scares me though! :)

About the dvd drive what model number is yours? is it grey with a black drive?

As far as speed goes shouldnt the fw 400 port on the motherboard be faster than any usb2 setup when optimized?

> As far as speed goes shouldnt the fw 400 port on the motherboard be faster
> than any usb2 setup when optimized?

The theoretical maximum transfer rates are 400 Mbit/s for FW400 and 480 Mbit/s for USB2.

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.

[ Edited by Yomgui on 2010/9/30 11:15 ]

[ Edited by Yomgui on 2010/9/30 11:18 ]

>> The theoretical maximum transfer rates are 400 Mbit/s for FW400 and
>> 480 Mbit/s for USB2.

> final speed depends on many parameters, and not only physicals ones. [...]

Thanks for your detailed explanation. Wikipedia confirms what you said:

"Although current high-speed USB 2.0 (introduced in 2001) is quoted as running at a higher signaling rate (480 Mbit/s) than legacy FireWire 400 (400 Mbit/s, available since 1995), data transfers over S400 FireWire interfaces generally outperform similar transfers over USB 2.0 interfaces. Few if any USB 2.0 device implementations are able to saturate the entire 480 Mbit/s, but this can be achieved with multiple devices on the same bus. Typical USB PC hosts rarely can sustain transfers exceeding 280 Mbit/s, with 240 Mbit/s being more typical. This is likely due to USB's reliance on the host processor to manage low-level USB protocol, whereas FireWire delegates the same tasks to the interface hardware (requiring less or no CPU usage). For example, the FireWire host interface supports memory-mapped devices, allowing high-level protocols to run without loading the host CPU with interrupts and buffer-copy operations. Besides throughput, other differences are that FireWire uses simpler bus networking, provides more power over the chain and more reliable data transfer, and is less taxing on a CPU."
http://en.wikipedia.org/wiki/IEEE_1394_interface#Comparison_with_USB

Quote:

Marvellous explanation, one that illuminates one fact: Computers are complex.

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.

I've made some profiling and results show me that 96% of time is waiting the result from the HD. But I've seen also that the time between the moment where application send the io request and the time when this io request is processed was very long...

I've found that increasing task priority for the sbp2 task (and also Helios task) give me extra time and I've reached the same speed as USB2.0 one (for my setup).

Now, I try to see how to get more speed than USB

Quote:

Maybe JCmarcos ment: can it be integrated in the Poseidon GUI ( or is that integrated in the stack, I know nothing about these things ) ? That wouldn't be a bad thing. But would it be possible ... I don't know.

Can you work on the Airport drivers next please :)

@Oepabakkes:

No it's not related: not same options, not same classes, and so on.
I can make something like Poseidon to have a continuity in the GUI.
But it's a preference GUI outside Poseidon, for sure.

@JJ: no, I don't want to touch something like this

[ Edited by Yomgui on 2010/10/1 15:50 ]

> > Can it be integrated in Poseidon

> Are you joking?
> /me slap twice jcmarcos !

Hey, don't slap me, I didn't even said that!

I don't see how another connectivity stack can be "integrated" into Poseidon anyway. Well, if we let fantasy run wild, one could imagine Poseidon enumerating ALSO the IEEE 1394 controller (and all its connected junk), aside from the USB controller.

But that can't happen. Let's concentrate again if Guillaume's achievements.

Quote:

You would be surprised how much software overhead USB really has .... IMHO USB is a typical PC interface with the guideline: "We have enough CPU power, so let's try to waste as many CPU cycles as we can for the low level protocol even though we have DMA ...."
OHCI1394 is definitely way more efficient there....

Yomgui

Ok got back to my place in LA. I tried to install the latest version and copied all classes, c: stuff, and devs as per readme and I dont think its working. Unit control doesnt see nor do any ohter hd tools. My Graid isnt coming up... the directions are confusing to me or I messed up or it doesnt work.. :(

pega-1

Do you think there is a chance of getting Helios integrated officially into Morphos? So that there is no need for user searching for files and downloading and configuring them?

[ Edited by magnetic on 2010/10/3 3:48 ]

Hi all, Yomgui,

My Sony handycam camera, worlds first widescreen cam, it was recognized in FWInspect
from the previous Helios release. This Helios, i see no prove it's plugged in. Tried
with option ramdebug booting the bootimage.

Grts Amigaharry
http://www.angelfire.com/amiga/ex

@AmigaHarry:
You DVcam is always seen by the FW chipset and Helios... just that there is no driver for it yet.

I'm working on that, I've recently finished the Isochronous receive support and coded a small example to grab the dvcam stream into a file (depending on dvcam it's MPEG2-TS or DV stream).

Today I've made modified this code and make a MUI gui using VLayer and FFMPEG to display the DV in realtime the video... it's quite impressive.

mencoder is working to reencode it into x264 video (dv footage is a 100MB file)....
When it finished I upload it on vimeo and edit this post when available.

[ Edited by Yomgui on 2010/10/3 23:48 ]

For people that don't see anything, please to read carrefully the readme: you need to make sure to have run "helios_rom_start" binary BEFORE any other ones!

In case to not have followed this strict rule: please reboot and try again!

Now: please to check this video, I think it will be a BOMB

http://www.vimeo.com/15521285

[ Edited by Yomgui on 2010/10/5 10:06 ]

yomgui
very exciting news on the dv video. And you did the famous screen within screen trick :P

I ran helios_rom_start in shell with snoppium running and I tries to launch files and devs but all come up as FAIL!

It would be cool if there was an installer as I may have not installed it right.

If ALL hardwares units are fails, please take a look to PCIScan output. And check if the FW unit is not taken by someone else.

Be sure also that helios_rom_start has been launched as first after boot and only one time.

Note also that your 1394 hw unit maybe broken, I've already seen that.
Send me your log

[ Edited by Yomgui on 2010/10/5 10:13 ]

Quote:

Interesting details. Could you explain to us what's the required scenario for Helios at startup?

It fascinates me, all this "run me before someone else grabs the harwdare", brings memories of Early MorphOS on Amigas...

Very, very impressive job, by the way. Being firewire much less common than USB, perhaps we could live without lovely user interfaces.

@jcmarcos:

Helios uses PCIX library... just check how API is designed in the SDK, so

PCIX library gives you possibility to set an "owner" of the PCI board object. Well, it's not a strict keeper as any software can use the PCI API without checking if the object is owned or not. But it's not my case: if I see that the PCI object is already owned the HW unit init fails.

Now, an other app setting this owning is the ohcimon of Frank Mariak, given in the morphos SDK.

It possible also that the OHCI HW doesn't respond correctly to my requests (ex: a reset doens't occure).

[ Edited by Yomgui on 2010/10/5 11:22 ]

Yomgui

I've used the fw ports on my peg2 with linux fine, so i know they work. (even had an ipod mounted over firewire with MOL and OSX!)

I do have the SDK installed can that be a cause?
And yes I always run the helios_start_rom command before anything on reboot.

Quote:

Great results - I saw Piru's post on Amiga.org whilst Morphzone was down. Shame about the thread pollution...

(Humbly asks) Do you have any plans to add isochronous send support (ie for supporting FW audio devices?

Quote:

Indeed!

Quote:

Out of interest, what MorphOS machine are you using (there are so many now )?
Just wondering if the lower-end Powermacs would be able to do this, or if you require a >2GHz G5 Powermac... (and, of course, a 3.x development branch)

Best Regards



Rich

@boot_wb: I'm using a MacMini G4@1.5GHz/64MB-VRAM (late2005).
I've also a Peg1 G3 and a Peg2 G4.

Yes I've planned to support FW iso tx, but I haven't any hw to check that (except my dv-cam maybe... but not sure and anyway need to implement AV/C class to support that).

But forget h264 encoding! takes too much time, for just few % of compression.

[ Edited by Yomgui on 2010/10/5 16:45 ]

Update:

In one of my previous post, I've said that I've not reached the USB transfer speed (is 23MB/s to copy a 700MB file located on a SFS partition, into RAM:).

I've supposed that was my code and I've tried to profile it.
After analysing profile data, I've not found major issues in my code that could increase more than 1 or 2 % the speed.

But yesterday I've found that I've forget to setup an important bus parameter: the GapCount.
I'm not going to enter in technical explanations about this value, but just saying that the default value is the max, so the bus is in the most secure mode to handle data.

Most secure = less speed rate.

By descreasing this value to a suitable one using manual operations, I've finally reached a 30MB/s speed using default Ambient copy and even 36MB/s (!!!) by tweaking it using the copy shell command and 1MB per SCSI cmd.

Now I need to make this value setup more automatic.

[ Edited by Yomgui on 2010/10/15 11:32 ]