> Has anyone ported or attempted to port Netperf to VxWorks? If so, I would
> appreciate information as to how successful the port has been. Even if the
> port has not been successful, I would still like to receive information
> concerning the problems that were encountered during the porting effort.
>
> Also, does anyone have any opinion on whether it would be possible to
> successfully port netperf to VxWorks within a reasonble amount of time
> (i.e., < 1 month)?
I felt that I should speak up on this a little. I did the work on the
VxWorks port that Rick recently posted to the mailing list. My
interest was primarily in the TCP_STREAM test (i.e. TCP throughput),
and that part of netperf should work reasonably well under VxWorks
(with the caveat that I only tested it on one particular CPU board and
ethernet driver).
All told, that work took me about 3 days once I figured out the
VxWorks environment sufficiently well (just to set the scale of the
porting effort). I did not try to do the CPU utilization portion, and
I didn't get around to prettying up some of the host info reporting.
The netserver side doesn't spawn any new tasks, so it can only handle
one sender at a time.
The main substantive problem remaining, and this affects the
UDP_STREAM test in particular, is interruptible system calls and alarm
timers. It turns out that despite having an SA_INTERRUPT defined in
<signal.h>, VxWorks does not provide any mechanism to interrupt read()
or recv() calls. I put in a call on this to Wind River, and what they
suggested to me was to use select() instead. This makes for some ugly
coding, but I suppose it's probably workable (presumably select()
would not add much overhead on VxWorks since it's not trapping into
the kernel like a Unix system call).
I have since gotten sucked off onto some other projects here, so I
don't currently have much time to spend on fixing up VxWorks netperf.
However, I would certainly be willing to advise anyone who wants to
work on this (please feel free to contact me). I hope someone can
manage to do the merge and get Rick a 2.1pl5 ...
Tom Pavel
Stanford Linear Accelerator Center
pavel@slac.stanford.edu http://www.slac.stanford.edu/~pavel/