> -----Original Message-----
> From: Brian J Beesley [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 26, 1998 3:35 AM
> To: [EMAIL PROTECTED]; Aaron Blosser
> Subject: RE: Mersenne: RE: any large groups that run GIMPS software on
> corporate computers?
>
> > I think, for many with security concerns, it would be
> preferable to set up a
> > "Prime Proxy" of some sort.
>
> As a network manager, could I point out that it really doesn't help
> security at all, though it may make the security manager's job
> easier. The point is, one "hole" in a firewall is just as dangerous as
> many.
Well, I guess so....not so much for security but more to improve the use of
Internet bandwidth. After all, the setup time for thousands of clients,
each sending their own data to Primenet, not only ties up bandwidth at the
workstation side, but also ties up the Primenet server more.
> I don't really want to restart this thread, but I thought the core of the
> US West problem was that there was a great deal more traffic
> between the participants and the server than should have been the
> case, due to the server going down, due to running out of
> exponents (back in v15 days). Though this traffic in itself should not
> have threatened US West's services, there was a coincidence with
> a probably unrelated problem resulting in poor service, which
> resulted in Prime95 being blamed because the PrimeNet traffic was
> "discovered" during the investigation into the poor service problem.
That was a consideration. However, I had set the network retry time to 120
minutes on each machine, and many of those machines already got exponents.
The claim US WEST is making, or made since I doubt they still believe it, is
that the software itself, in the process of all those fun FFT calculations,
was tying up the processor. We all know it only takes idle time, but when
you look at performance monitor in NT, all you see is that NTPRIME.EXE is
taking between 90-98% processor time, so they assumed it was hogging the
processor. Needless to say, the US WEST folks don't quite understand that
it doesn't take CPU time from other processes, only the idle process. Oh
well...sigh...
The real problem they had was that call processors would get a huge delay
when they tried to hit the mainframes to query the database for a phone
number or customer. From what they say, normally the results come back in
5-10 seconds, but on this day it was taking 5 minutes or so. Well,
hmm...seems more likely that the mainframe was choking.
Especially considering that I had the program on machines in Phoenix,
Denver, and Omaha, yet only the Phoenix machines were having problems. Each
site hits a different mainframe, so it only makes sense that mainframe
problems are more likely suspect.
Okay, I'm venting again...breathe...relax... :-)
> If you have an intermittent (dial-up modem or ISDN) connection and
> the cost of making calls is non-zero, then, as Aaron says, it's
> definitely cheaper to batch up data locally & send it in one block.
Good points...before my cable modem access, I had 4 machines at home all
going through a dial up on one machine. It would have been easier to
coordinate the Primenet access with a "batch" transfer of some sort...
> > Or let's say you have many machines on a network that isn't
> > connected to the internet at all.
>
> Eh? Does anyone outside of a treatment ward for terminal paranoia
> still work this way??
Hey, it's the only way NT is C2 certified...don't connect it to a network
:-)
> > It sounds like a good idea to me, and obviously I haven't explored the
> > possibilities too much, but that's the general idea.
>
> It *is* a Good Idea - especially for sites with a largish number of
> users - but the *real* benefits are in terms of reducing the load on
> the "master" server. OK, we have some way to go yet before the
> problem becomes critical, but as a distributed project grows, the
> need to distribute the server functions also gets more urgent. This
> is on the grounds of redundancy (no single point of failure) as well
> as of load-sharing.
Well, when I had thousands of new machines hitting Primenet back in May, it
did cause problems...fortunately Scott got on the ball and got it going, and
it was also related to the 5.2M+ problem, but there were also times (Scott,
correct me if wrong) that Primenet was already maxed on connections and had
to refuse other incoming connections.
For 4000 or so machines, connecting intermittently, it's not too bad.
I wonder what the folks at SETI@Home plan to do...they're anticipating many
thousands of computers...hmm...
