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: [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/
