Volkswagen Passat Forum banner

1 - 7 of 7 Posts

·
Registered
Joined
·
2,500 Posts
Discussion Starter #1
I've been looking for a firewire PCI card and have been curious about the new 1394b... Couple of questions:

a. whats up with the 2x longer pci slot (64 bit pci??) will it work with the older 2.x pci slots??

b. what devices will be using this tech and will it be worth it?

c. okay it's 800mhz but, can any device send info that fast (like a 7200 HD)??
 

·
Registered
Joined
·
4,095 Posts
upshot said:
I've been looking for a firewire PCI card and have been curious about the new 1394b... Couple of questions:

a. whats up with the 2x longer pci slot (64 bit pci??) will it work with the older 2.x pci slots??
yes. I have a raid controller that is 64bit and it works fine in 'narrow' pci slots. same with my gig-E net controller (ALL good gig-E cards are 64bit...)

normally its 33mhz and 32bit. the 'wide' slots are 64bits. some may or may not be 66mhz also. there is also pci-express coming out soon. and in fact, pci (regular) can run even faster than 4x. but it is backwards compat.

b. what devices will be using this tech and will it be worth it?

c. okay it's 800mhz but, can any device send info that fast (like a 7200 HD)??
b) if its cheap, get the card. nothing 'needs' that kind of channel room; but otoh, if you share the bus with a few drives or devices, it DOES make sense to have extra bandwidth since each device is going to timeshare that wire.

c) no single device can even chew up regular firewire. but being able to CLOCK at that rate is different from STEADY USE of it. good example, when 100baseT ether came out, laptops started appearing with pcmcia cards to speak 100bT. which was a joke since the pcmcia was essentially isa bus speed and there's no way in hell isa can keep up at 100bT. but it CLOCKED at that speed- it just had a LOT of space and gaps between each 'breath' (so to speak). in fac t, with buffer losses, it was FASTER to go 10 instead of 100 due to buffer losses and retries and timeouts.

higher speed bus isn't always better. usually it is, but not ALWAYS.
 

·
Registered
Joined
·
2,500 Posts
Discussion Starter #3
Hey, I knew you'd chime in mr.works... :wink:

So are you saying that regular 1394a devices daisy-chained can take advantage of the extra bandwidth at the PCI? Guess I didn't know this was the case... I thought you'd have to get a device thats running 1394b to get the "big-pipe".

Thanks for your input... It's always appreciated!
 

·
Registered
Joined
·
4,095 Posts
upshot said:
Hey, I knew you'd chime in mr.works... :wink:

So are you saying that regular 1394a devices daisy-chained can take advantage of the extra bandwidth at the PCI? Guess I didn't know this was the case... I thought you'd have to get a device thats running 1394b to get the "big-pipe".

Thanks for your input... It's always appreciated!
I don't know if the channel that runs at 800 (the 2nd gen of firewire) can clock at dual speeds at the SAME time. scsi can, for example; if you have slow devices and fast ones (like scsi2 vs scsi3) then while scsi2 devices 'talk' the channel runs at slower rate since the device can ONLY clock out bits at 10 or 20mhz (etc). when that device is thru, the channel goes to the speed of the next device in line. ide never was like that in the past, the slower device ALWAYS limited the channel speed.

I don't know if this is the case with FW. I'll poke around a bit and see if I can find out.

you don't mean extra bw of PCI - you mean extra bw of the FW bus.

in the easy case, if your devices can clock out bits at FW2 speeds, then clearly you will get better channel use if you add some devices to the chain that don't 'eat up' the whole channel but share part of it. simple example, if you have 2 devices that run at 5 (max) and the channel can support 10 (to pick round numbers) then you can support 2 devices on that channel and still run each DEVICE at its full speed. otoh, if the sum of bandwidths of the devices exceeds the total channel cap, then you start to slow down the devices since you 'ran out of room'.

obviously older devices won't magically run at 800. thinking it thru, the controller will have to sense what devices are out there (probe and learn of them when there is a topology change - ie, new devices come online) and the controller will HAVE to lower its speed down to 400 for the legacy devices. its not clear to me if the channel STAYS at that speed or if it switches back and forth like scsi does. scsi was never designed to be cheap and low cost - but all other things are (usb and fw are low-cost things). so its possible that devices can't just 'ignore' stuff on a bus that talks faster than it can decode. in that case (like ide) the whole channel might have to slow down due to the presence of the slower device.

then there's hubs. sometimes you literally share the same channel for all devices and sometimes you have a repeater/bridge in between. I'll have to read up to see how this affects things (I don't know right now).

for simplicity, since the controllers are so cheap, I'd have one for the slower devices and another for the faster ones (if you have any 800 FW devices). controllers are cheap enough these days..
 

·
Registered
Joined
·
4,095 Posts
also, another thing - since fw tends to be from realtime devices (like video sources), its more like a streaming protocol. ie, you do NOT want to drop bits or cause delays.

for that, I'd use one controller for a video camera and put JUST that device on it. all others (like drives, etc) could go on another controller. that way you never have a choke point on the realtime source; and drives (which aren't realtime, once the data is buffered in the host cpu) can afford some retries or delays. but its important you capture the source drop-free and for that, I strongly suggest giving the camera (if you have one) its own independant controller channel (or pci card).
 

·
Registered
Joined
·
2,500 Posts
Discussion Starter #6
Well... I don't have any 800 devices and yes I'll be using a miniDV deck and the ADVC-100 (I know you have one of those...) I also have a plexsor external dvd burner and a collection of external drives that I alternate beween fire and usb2...

Guess that's another question, usb2 or firewire? which one is superior? usb2 is 480 so it's maybe a tad quicker?

I have a 6 and 4 pin connection on my asus pundit but, truth be told they are on the front of the box and I'd like to clean up my area (neverending battle) by connecting to the pci in the rear.... So thats the whole enchalata.

Guess I should just go with the cheepo 1394a and wait till I actually have a 1394b device to warrant the interface....
 

·
Registered
Joined
·
4,095 Posts
oh, right - burners are also mostly realtime devices. yes, they have burn-proof and such, but its still a good idea to give things that 'stream' their own channel.

usb2 is still inferior. from what I've heard, it still isn't as realtime-capable as FW is.

oddly enough, on linux, FW is inferior! usb1 and 2 are better designed and work better. FW sits on top of scsi (abstraction layer) and doesn't really do topology discovery by itself - you have to tell the O/S to rescan the bus (literally). hotplug on FW isn't mature on linux yet. but it IS with usb2! odd, huh? its because usb does NOT sit on scsi and is more integrated in a hotplug sense.

still, FW is a better design for realtime devices. its no wonder that video sources are pretty much only FW and not usb.

I think that FW is more isochronous (did I spell it right?). it keeps the stream going steady and doesn't burst or pause or clog-up like usb might.
 
1 - 7 of 7 Posts
Top