Whoops. Reply to one != reply to all.
On Sat, Sep 25, 2010 at 9:37 AM, Giovanni Tirloni <gtirl...@sysdroid.com> wrote:
> What options are you using to mount the NFS share ? Depending on your safety
> requirements, you might want to try async/sync and different rsize/wsize
> values.
I'm using a rsize/wsize of 32768. The drive is mounted async.
ALSO. I am a giant turkey and should clarify that the FPGA is sending
data out at 4.76 mega*bits* a second (my engineer said bytes... iftop
shows bits, someone else confirms). Still nothing that NFS should
choke over, just the writes aren't fast enough.
A basic diagram of how this works -
Controlling Electronics ---> Modem FPGA -------> desktop --NFS--> dataserver
To clarify on James Grinter's point ("Are these dropped packets on the
NIC stats, or reported at the RPC/NFS level?") - The FPGA has some
sort of buffer that is filling with data from the controlling
electroncis and dropping packets before they get sent over to the
desktop, because the desktop isn't writing fast enough. Changing the
TCP window settings on the client and host have brought that number
down *significantly*, where the FPGA had only dropped 11 packets out
of like 40000+, but we're looking for 100% retention.
>From this thread, I think my next steps are:
1) Modeling IO with iozone
2) Using wireshark to monitor window zero/full errors.
3) Tuning TCP from there.
Unfortunately, upgrading this NFS server won't work. We purchased an
X86 machine full of disks because we can't really afford a netapp or
other storage, but I don't think we're throwing anything at it that it
cant do. They're all sequential writes.
I'd prefer to stick with one OS in this lab for many reasons, but if
it turns out I have to switch for this minuscule amount of streamed
data, so be it.
_______________________________________________
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/
