flat assembler
Message board for the users of flat assembler.

Index > Windows > IEEE 1394

Author
Thread Post new topic Reply to topic
Dr.X



Joined: 29 Aug 2003
Posts: 60
Location: St. Petersburg, Fl. USA.
Dr.X 15 Jan 2005, 13:00
Has anyone here tried comunicating with IEEE 1394 (firewire) devices yet?

thanks.
-Dr.X
Post 15 Jan 2005, 13:00
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 15 Jan 2005, 15:26
Nope, only used one - interesting to see that FireWire at 400mbit beats USB2 at 480mbit.
Post 15 Jan 2005, 15:26
View user's profile Send private message Visit poster's website Reply with quote
comrade



Joined: 16 Jun 2003
Posts: 1140
Location: Russian Federation
comrade 15 Jan 2005, 18:13
How is that possible?

Its like saying your car at 40 km/h is faster than mine at 48 km/h.
Post 15 Jan 2005, 18:13
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 15 Jan 2005, 18:54
Not really, comrade - there are a few things to consider. First, USB2 wasn't really designed with the purpose of giving one single device 480mbit/s - but rather to have a lot of somewhat slower devices.

IEEE1394/Firewire, on the other hand, was designed with *really* high speed applications in mind, and the protocol includes things like bandwidth reservation and whatnot.

USB2 also seems to eat up a fair amount of CPU when operating at high speeds, firewire ate up somewhat less.

I did a test with my newly purchased external HDD box, with both USB2 and 1394 connections. I selected ~14GB of files (4+ megabyte each) and copied them to my drive. I let the copy run for one minute or so, to have the estimated time left stabilize (I didn't feel like actually copying all 14gigs).

For USB2, it said 18 minutes left. For 1394, it was 10 minutes. Interesting, huh? It's not a cache issue, as the drive was de+re-attached to switch connection type. Of course it might be the performance of my USB2 controller (add-on card) or firewire controller (SB Audigy), or the chips in the harddisk case.

But I do have the impression that firewire is faster in general, because that's what it was designed to do (and besides that, there's a 800mbit version of firewire now Smile).
Post 15 Jan 2005, 18:54
View user's profile Send private message Visit poster's website Reply with quote
Dr.X



Joined: 29 Aug 2003
Posts: 60
Location: St. Petersburg, Fl. USA.
Dr.X 16 Jan 2005, 02:47
Quote:

For USB2, it said 18 minutes left. For 1394, it was 10 minutes. Interesting, huh?


That's _very_ interesting. Especially since I just tested copying a 10 gig file (on the same drive, just from one folder to another) and it says 12 min. remaining. So it would seem that the firewire is faster than my ata drives.

I just wanted to see if I could interface with my firewire digital video tape recorder. I have a video editing software that is capable of it. So I know it's not impossible. There's probably some complex api. ack! Confused

-Dr.X
Post 16 Jan 2005, 02:47
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 16 Jan 2005, 11:25
Quote:

That's _very_ interesting. Especially since I just tested copying a 10 gig file (on the same drive, just from one folder to another) and it says 12 min. remaining. So it would seem that the firewire is faster than my ata drives.

No no, I copied from the external HDD to one of my internal drives! Copying from one location to another on the same drive (or other partition on the same drive) is going to be slow, and really has nothing to do with 1394 vs USB2 vs ATA.

Quote:

I just wanted to see if I could interface with my firewire digital video tape recorder. I have a video editing software that is capable of it. So I know it's not impossible. There's probably some complex api. ack!

Humm, you want to do it programatically? I don't know how this works; either there's some proprietary driver, otherwise it's probably just one of the win32 media/capture APIs, which isn't going to care much which source you're using.
Post 16 Jan 2005, 11:25
View user's profile Send private message Visit poster's website Reply with quote
scientica
Retired moderator


Joined: 16 Jun 2003
Posts: 689
Location: Linköping, Sweden
scientica 16 Jan 2005, 12:28
/me get's a thought about Mbps <=> MHz, and thinks, can a 3GHz CPU be "beaten" by a CPU 2.2GHz... that sort of makes IEEE1394 > USB2 beeing fully reasonable (just plain figures doesn't give the truth about performance)

Quote:
For USB2, it said 18 minutes left. For 1394, it was 10 minutes. Interesting, huh? It's not a cache issue, as the drive was de+re-attached to switch connection type. Of course it might be the performance of my USB2 controller (add-on card) or firewire controller (SB Audigy), or the chips in the harddisk case.

well, that doesn't neccesary mean thigns aren't chached, but as I don't know jack s*t how the chache/buffer system works in windows I can't say if un+re-mounting will clear the cache(s).
Also, as you say, you x-fered 14GB in "small chunks" - that could also explain it, it seems USB2 has more overhead per file than IEEE1394, would be interresting if you could tar/(put them in a defalte archive) them to onebig 14GB file and xfer that.
Post 16 Jan 2005, 12:28
View user's profile Send private message Visit poster's website Reply with quote
Dr.X



Joined: 29 Aug 2003
Posts: 60
Location: St. Petersburg, Fl. USA.
Dr.X 16 Jan 2005, 18:40
Quote:

No no, I copied from the external HDD to one of my internal drives! Copying from one location to another on the same drive (or other partition on the same drive) is going to be slow, and really has nothing to do with 1394 vs USB2 vs ATA.


You're right. I don't know what I was thinking. Yes, moving from one drive to another is faster.

Quote:

Humm, you want to do it programatically? I don't know how this works; either there's some proprietary driver, otherwise it's probably just one of the win32 media/capture APIs, which isn't going to care much which source you're using.


I'll have to read up on that. I was hoping to get at the hardware level but I think even the media api's might help me to better understand it.

-Dr.X
Post 16 Jan 2005, 18:40
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2023, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.