🚀 go-pugleaf

In article <48auio$mjd@crash.microserve.net>,
John Core <johncore@frackit.com> wrote:
>keith@ksmith2.ksmith.com (Keith Smith) wrote:
>>Doesn't have to be.  A lot of the delays are with the news software,
>>which does a whole lot of stuff to insure no duplication among other
>>things.  With adequate memory, and if you can be relatively sure you
>>aren't downlinking any duplicates you can speed up memory unbatching by
>>a LARGE factor.  like 4-8 times as fast.  I'm working on a custom news
>>system for the satellite feed.  It makes a LOT of assumptions, but is
>>totally designed for SPEED, SPEED, SPEED.  It is going to be a real
>>memory PIG, and will probably require at least 32MB of RAM to run
>>effectively.
>
>Our local ISP uses a P90 running Unixware II with 32 megs of ram and it serves 3
>feeds at 3 articles per second.. Let's not blame all our problems on hardware.

I wasen't I was blaming the software. . . I mention the 32MB figure
because at that level you can put some rather large data structures in
core where they are fast to get to.

Much of the news software was written to be run on rather smallish
machines.  In the quest for faster processing, you can pull a few tricks
if you KNOW certian things will fit in internal structures.

>BTW we are setting up the same exact thing to receive pagesat. It would be
>nice if pagesat could blow that away, but no such luck even at the future
>promised 115k.

It'll stress it.  Heck the Current 12K feed stresses it.  200MB a day of
data is a LOT of data.  If they ever start pumping at a maxed 115K
that's gonna push close to 2G/day of compressed news articles.

That's the size of my current news DISK right now :).