Quote:
Originally Posted by Greg McKaskle
I haven't seen the code, but my understanding is that at last some of the writes were done a byte at a time -- likely with the iostream ++ syntax. That plus the no-delay resulted in lots of packets that made the router unhappy.
I agree with your comment about no-delay. I'd expect the latency to be around as much as 100ms.
Greg McKaskle
|
Hi Greg,
Yeah, I could believe that. Given the number of packets in normal driver station comms, I could see that there's likely a fair amount of 802.3x flow control packets if the switches are being overrun. However, this sounds like a hack. VxWorks is a very deterministic O/S. If it's resorting to very short payloads, it's likely because there's a resource starvation going on someplace and this is a quick hack to get past the problem. I've seen multiple places in WPILib that look like desktop folks trying to understand operating in real-time -- unsuccessfully. But, they keep introducing additional layers of abstraction hoping to make things easier. However, abstraction layers have a price. I suspect that this small payload issue is one of those prices.
How much longer are we using this control system? There are many ways to improve performance on the 'bot without losing the 3 language support. I've been a long time user and developer on VxWorks. But the reality is that WRS, really isn't doing much to promote the use of VxWorks on the 'bot. They're really missing an opportunity, IMHO.
Thanks,
Mike