Steve Modica
Forum Replies Created
-
Just guessing here, but I’d say your storage is probably the issue. People don’t understand that bandwidth is not what’s required to keep up with video. It’s latency on a per frame basis. Certainly that adds up to a certain bandwidth, but someone can have a very high bandwidth, but very choppy (IE variable) latency. We see it all the time.
AFP works great for capturing. It keeps the latency down, it handles security and authentication and it is very efficient in 10.5 and 10.6 (it seems to scale much better in 10.6).
I spend most of my day testing different storage protocols and solutions looking at latency. SSDs are next. We have to figure out how to make those handle this stuff.
-
Since you’ve isolated this to a single server, have you considered running that server on a port of its own for a short while? You should also get the logs out of this server and the TCP stats. When the port goes away, if there’s enough time, you should try and get a tcpdump output. (In fact, it would be good to do that even while it’s working. It might shed some light on what’s on the wire.)
Older linux kernel TCP stacks had some serious TCP ordering issues. I think those were corrected around 2.6.20.
Another test, when this thing goes away, can you still ping?
Steve
-
We have customers setup that second port with jumbo frames back to their storage or server. With jumbos, you can go 70MB/sec vs 50MB/sec using Apple’s AFP protocol. (this assumes your storage can go that fast.)
In larger configs, we’ll put in an Xserve with a quad card or larger and link aggregate the ports. Then setup jumbos.
The benefit is that your video editing traffic is on a high bandwidth, dedicated network and your email, web browsing, dhcp etc etc is all on the first port.
Steve
http://www.small-tree.com