frame serving over network?

[BrianP]

I recently upgraded a second PC with the intention of making it a dedicated MPEG encoding box. I was going to export a project from my editing PC and send the file over to the second PC for encoding. However, Win2000 balks when I attempt to transfer a huge (12GB) file across my network.

Is frame serving over a network feasible? Will the CPU overhead on the serving PC be low enough to justify serving it to the encoding PC? Any other suggestions?

[LvR]

Brian ;

I dont know about the health of your network there. Regularly moving huge (10G+) video files over the network here without a problem at around 2.5M/s on a 100Mb link between W2K and W2K or XP machines.

Edit;
Correct, and sorry about the W98 AZ - habit is a bad thing!

[az]

Definately NOT from/to an win9x machine. Win9x uses FAT, which only allows files up to 2 (FAT16) or 4 GB (FAT32). Maybe that's the problem for you too, BrianP?

AZ

[Brian Ellis]

Are BOTH machines NTFS?

[BrianP]

Both machines are Win2000 and use NTFS. The destination drive is an older Fasttrak33 array, but still 16GB of empty space.

I can't recall the exact error, but the traditional Windows file copy animation starts and it says it will take about 15 seconds. That progress bar completes and then it says it will take about 290000 minutes. (That's almost 200 days!) After some indeterminate amount of time, since I leave the room to avoid watching said copy animation, the error box pops up. I'll have to get the exact error message, but it's nothing that's immediately illuminating.

I did a number of 1.7GB transfers across the network with no problems. Each one takes about 3 minutes.

The system drive on the destination PC definitely has less than 10GB on it. Although this isn't the actual drive destination, might that be cause? I wonder if Windows writes little temporary files to the system drive as it's copying to the actual drive. If that gets full....

I have the second PC on a dual boot with Win2000 and XP, so I'll try sending the file over when the OS is XP and see if that is any different.

[az]

I had the same problem copying a 3.6 GB file from FAT32 to FAT32, through two cheap Realtek 100mbit cards and a cheap 100mbit hub. Both computers used the cheap ECS K7S5A. I think it worked after one or two retries.

AZ

[wkulecz]

I've no problems moving 20+GB files across my 100BaseTX switched network (W2K and Linux). Large transfers of DV files take about 40% of their playing time -- 2hr video transfers in about 50mins. Given that DV is about 3.6 MB/sec this means I'm geting ~8MB/sec across the network. The copying "flying folder" dialog displays some laughably wrong numbers for time remaining.

I can edit video from a network drive, although the extra latency makes it less than optimal for complex edits, I also regularly encode to MPEG2 from or to a network drive. What would be most convienent is capture to a network drive, but the capture apps don't seem to allow this.

--wally.

[BrianP]

I tried a 4.5GB file and got the same error. I tried again but cancelled after a couple seconds. A third time and it was successful.

So then I tried the 12GB file again. On a whim I cancelled it after a minute, thinking maybe there was some caching going on and if I transferred again it would already have that cache as a "head start." Probably completely faulty reasoning, but whatever. I tranferred it again and this time it worked. It took probably half an hour or so.

My hardware is all Linksys, btw.

[az]

Mainboard? Some boards sometimes "lose" bits, which may screw up your connection, or the file (I think).

AZ

[BrianP]

Mainboard?

Main PC: Iwill KK266-plus. 1GHz Athlon. 512MB.
Second PC: Abit BE6-2. 1GHz P3. 256MB.

[Flying dutchman]

Definitely sounds like a PCI busmastering problem to me.

I have something similar on one PC (a Gigabyte Pentium 3 board with Via chipset). Busmastering problems all over the place (dropped frames when capturing video, data corruption when using a firewire card, clicking noises in the sound card, large copies failing over a 100 mbit network, unable to play DVD's without dropping frames etc).
That's when I swore never again to buy a motherboard with Via chipset. And I probably won't ever buy a Gigabyte board anymore either.

[Brian Ellis]

I've had the infinite time syndrome when transferring umpteen GB-worth of multiple files, using an old-fashioned thin coax network and TCP/IP (or other) protocol, peer-to-peer. I just ignore it and it goes away after a time and the transfer is achieved normally. I guess that the software is probably programmed with the figure as a single precision integer scalar for the time variable. If this exceeds 64,000-odd of whatever unit is chosen (e.g., packet cycles), then the value will go haywire. Bad programming, that's all, but we are used to that, aren't we?

A similar thing is probably the cause of the red figure syndrome when generating a large mpg file in MSP.

[BrianP]

Although I lucked out with my VIA board being compatible with my DVRaptor (KT133A Chipset), I definitely will avoid VIA in the future. I think anyone involved with video is aware of this by now, but it also seems to apply to general computing as well.