This paper was somewhat famous in the Berkeley system department when I was there; the lore was that it was the perfect academic system that proved a point but crashed ... frequently.
Maxima's primep takes 360ms on the 1024-bit one for me, so seems quick enough to stick into the build.
It sounds like the chance if it passing the test is around 10^-15 using the default values; which seems sufficient for a build test which is run many times.
We see a lot of both sides of this at BR (http://buildingrobotics.com/) -- we are actually BACnet experts, but also provide a really novel user experience on top of this legacy protocol. One thing I'd add is that many of the "legacy" industries have evolved in a way that's very different from what the Internet crowd expects and so you can't always make the same assumptions.
Also, it might be "unsexy" but buildings consume 70-ish percent of US electricity, a lot of which is controlled by BACnet and friends... and it turns out there's a ton of low-hanging fruit that's only a (carefully crafted, ASN.1-ish) UDP packet away..
If it's just a few streams at high frequency, my take would be to bucket it (eg every second or something) and stick it on your favorite database. You could use postgres arrays, the json columntype, or frankly just a blob in those rows containing all the data for a second.
You can then write some simple postgres queries to create the views your talking about and won't have to mess with any of the "look what I wrote last week" "databases".
Can you talk a little bit about how many nodes it takes to maintain that write rate? We have our own system that's currently handling around 1% of that on a single node, with decent headroom but I've been looking for ways to distribute it. Certainly word on the street is that OpenTSDB performance is not good, at least relative to the resources you throw at it; however since it's based on HBase you can keep scaling even if it's expensive.
