Yeah I guess we are still a long way from true remote monitoring of shopfloor activities using tcp. However, the txn speed greatly improves for segmented networks (using switches etc) 'cus collisions are near to zero. Anyway, the monitor refresh rate issue is a good one.
--- In [email protected], Rick Bullotta <[EMAIL PROTECTED]> wrote: > Last comment: Let's not forget that many monitors repaint well less than 100 Hz! > > ---- [email protected] wrote: > > > > > > Hi all, > > > > Just to add to this, you would be much better off displaying > > 'high frequency' data in a more usable format. So instead of trying > > to update a gauge every 1/100th of a second, show the min/max > > value range for the last 2sec with a 1/10th of a sec (weighted) > > average as the 'current' value. Update that a couple times a > > second and you will get all the information anyone needs. > > > > Ronan Oger wrote: > > > > > Guys... > > > > > > Don't push your SVG update rates too high. In my opinion there is nothing to > > > be gained in going past 20Hz (20 updates/second), and plenty to be gained > > > from staying below 10Hz (10 per second). > > > > > > No matter what you intend to do, you need to allow for the transport layer. A > > > 100-Hz update rate is meaningless if you have a 100ms lag When you do > > > traceroute tests, you will see that the delays you can expect on the internet > > > are 0.3 seconds for round-tripping.... With that kind of performance, you are > > > seriously wasting your time if you are sampling at 10x or 20x your lag... > > > Might as well go with 5-20Hz.... That's the best you can expect to need if > > > you use tcp systems. > > > > > > A comparison that may be useful to you guys... I've been doing a lot of > > > monitoring systems work using the Micromuse Netcool messaging infrastructure. > > > For larger applications, you end up needing to send your signals to a > > > concentrator of some kind, even if it is to allow for scalability and > > > auditing purposes... With Netcool, we find ourselves working with a 2-second > > > lag due to the 2-step forwarding (alert event->central bus, bus->monitoring > > > client). > > > > > > The point in the end is that you will be hard pressed, in my opinion, to > > > require anything like 100Hz update rates. > > > > > > Finally, consider the scanning rate of your monitor. There is no point in > > > doubling the scanning rate of your monitor, and even the best PC struggles to > > > get past 100Hz updates. > > > > > > While it's true that instrumentation sampling rates may have high speed > > > requirements for such things as closed-loop control, human beings are far > > > slower with this stuff, and there are plenty of reasons why there is no need > > > to go past 20-Hz when showing input to the user. > > > > > > I propose to you that the key performance criteria in all of our real-time GUI > > > tools is not refresh rate but transmission speed. > > > > > > Ronan > > > > > > On Tuesday 11 January 2005 12:08, Rick Bullotta wrote: > > > > > >>I think the "bottom line" is that a solution involving ASV, inside a > > >>browser, with a real-time 100Hz update, is highly unlikely, but custom > > >>solutions using Batik, SharpVectorGraphics, or Mobiform may be possible. > > >> > > >>---- [email protected] wrote: > > >> > > >>>Hi, > > >>> > > >>> > > >>>>You could probably feed that with a streaming feed over a socket, > > >>>>but to the best of my knowledge there is no way to do this in > > >>>>JavaScript. > > >>> > > >>>In Batik it works just fine. I have partially impl. the SVG1.2 Sockets > > >>>using JavaScript in Batik. > > >>> > > >>>see http://jan.kollhof.net/projects/svg/playground/ > > >>>or the SVG IRC client here: > > >>>http://jan.kollhof.net/projects/svg/examples/index.xhtml > > >>>they only work in Batik. > > >>> > > >>> > > >>> > > >>> > > >>>Jan > > >>> > > >>> > > >>> > > >>> > > >>> > > >>>----- > > >>>To unsubscribe send a message to: > > >>>[EMAIL PROTECTED] -or- > > >>>visit http://groups.yahoo.com/group/svg-developers and click "edit my > > >>>membership" ---- > > >>>Yahoo! Groups Links > > >> > > >>----- > > >>To unsubscribe send a message to: > > >>[EMAIL PROTECTED] -or- > > >>visit http://groups.yahoo.com/group/svg-developers and click "edit my > > >>membership" ---- > > >>Yahoo! Groups Links > > >> > > >> > > >> > > > > > > > > > > > > > > ----- > > To unsubscribe send a message to: svg-developers- [EMAIL PROTECTED] > > -or- > > visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" > > ---- > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > ----- To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ---- Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
