Patrick Cable <p...@pcable.net> writes:
> I have a device that sends out information at 4.7 Megabytes a second.
> I have a desktop that receives the data from this device that runs Red Hat
> Enterprise Linux 5.5. They are on the same switch, a 24-port Juniper EX2200.
>
> When I write the data to the desktop on the local filesystem, there's no
> dropped information. When I write the data to an NFS share, the device
> reports dropped packets.
[...]
> I find it hard to believe that a machine on the same (recent, gigabit)
> switch can't write out 4.7MB/sec. Am I wrong?
No, it should be fine doing that. One test that might be illuminating, if
painful, would be to try running 'while sleep 1; do sync; done' while doing
the capture and see if that will smooth things out.
While I would have hoped more modern systems have improved things, it used to
be back in the bad old days when I was working with DV capture on Linux that
the system had plenty of average bandwidth to write the stream, but would
batch work until the bursts were blocking long enough to drop frames.
That hack was my cheap test for figuring out that having the kernel / app
flushing more often, so lowering the peak requirement, would fix things.
If it does, having your application flush the output while writing should help
sort things out. (Traditionally, fsync from another thread works...)
Regards,
Daniel
--
✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
_______________________________________________
Tech mailing list
Tech@lopsa.org
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
