On Tue, 24 Apr 2012 21:06:42 +0200, Casper Bang <[email protected]>
wrote:
And yet, I would think F1 people, eager to cut even a couple of ms off a
time, would prefer native. I know that the various super-computers at
Today I don't know. At the time quite a number of people were sceptical
about Java being able to fulfill the job and we had the pleasure of
surprising them. We did it nicely and easily from the performance point of
view. The only important thing was object pooling (it was Java 1.4). We
never had to perform specific optimizations - I don't remember the exact
numbers, but something like 95%+ (precisely, it was near real time, not
pure real time) of data being delivered within I believe 0.1 sec. People
were worried about the impact of endpoints running in clients (data
analysis tools were and I suppose still are pretty CPU intensive and they
didn't want to suck CPU from them), but Java was running well below 10%.
Probably with some optimizations we could do more, but today with Java 6
it would be extremely faster without much hassle (and of course I would
get rid of the object pooling). The GC pauses were never a problem for
runs of a few hours (the system couldn't be absolutely stopped for two
hours, the typical race duration, but even during tests, which AFAIK last
all the day long, at least as far as there's sunlight, it was considered
an annoyance the need of a restart).
We had a very serious bug during the final tests that could have been a
showstopper, but it was due to an explosion of the number of sockets in
certain rare circumstances - nothing related to CPU or memory problems.
Sadly, the utility provider does not expose anything and is really only
interested in the billing aspect. I have installed a secondary
electricity
meter (3-phased Kamstrup 382), while the utility provider installed water
and heat (hot water) meters (Kamstrup 61 and 610). Almost all modern
meters
have an optical interface (used for on-site installation, troubleshooting
etc.). I build a simple RS-232 (though I access it over USB adaptor) IR
circuit and started
probing:
https://fbcdn-sphotos-a.akamaihd.net/hphotos-ak-ash4/419319_3274289293197_1146362123_33320716_52584424_n.jpg
The trick then is to figure out the right connection (parity, stop-bits,
data-bits, handshaking, speed) and of course, the actual protocol itself
(the hard part). By analyzing traffic dumps between the public available
support application and the meter, it is possible to infer the
interesting
commands. I'm not there yet, but have plans to share everything when
ready.
It's a little off-topic for this forum, but if you'd like to know more,
you
are welcome to drop me a mail. :)
Thanks for the info. Sure I'll do, in the meantime I'm going to see
whether that product or a similar one is available on the market here.
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
[email protected]
http://tidalwave.it - http://fabriziogiudici.it
--
You received this message because you are subscribed to the Google Groups "The Java
Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
