Itanium finally passes Alpha at HP

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message
news:cgv020$bvu$1@pegasus.csx.cam.ac.uk...
> In article <cgut0k$dj0$1@nntp.webmaster.com>,
> David Schwartz <davids@webmaster.com> wrote:
>>
>> If you look at the way they created the test, the 'chat' test is
>> really
>>just a measure of how fast you can do context switches. With HT (and this
>>ridiculously unrealistic type of workload), you need half as many context
>>switches. Only an idiot would design a chat application such that a
>>context
>>switch would be needed every time the server wanted to change which client
>>it was working on behalf of.
>
> Eh? Why? That is precisely what you want to do to get security,
> without having to be very clever. I agree that this is an unusual
> requirement, but it is not unreasonable.

ircd, the oldest chat system still running with half a million or so current
users, does all operations in a single thread because that removes the need
for context switches, synchronization, and message sequence tracking. AFAIK
there's not been a security breach in over a decade.

I have no idea how IM systems operate, since (with the exception of Jabber)
they're not open source. However, I can't imagine that AIM servers have 100
million threads, one per user. That is clearly unreasonable with current OS
designs.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In article <v2KYc.31833$JG7.15283@hydra.nntpserver.com>,
"Stephen Sprunk" <stephen@sprunk.org> writes:
|>
|> ircd, the oldest chat system still running with half a million or so current
|> users, does all operations in a single thread because that removes the need
|> for context switches, synchronization, and message sequence tracking. AFAIK
|> there's not been a security breach in over a decade.

And CICS did the same. But, in order to deliver that security, they
have to impose a lot of constraints. One slip, and you have a
security breach - been there, seen that :-(

|> I have no idea how IM systems operate, since (with the exception of Jabber)
|> they're not open source. However, I can't imagine that AIM servers have 100
|> million threads, one per user. That is clearly unreasonable with current OS
|> designs.

What is unreasonable is that there are no current designs that can
handle it. Nobody is claiming that every system should be able to
work that way, but the fact that none can is not good.


Regards,
Nick Maclaren.

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

David Schwartz wrote:
> "Robert Redelmeier" <redelm@ev1.net.invalid> wrote in message
> newsyrYc.14774$af6.13168@newssvr22.news.prodigy.com...
>
>
>>In comp.sys.ibm.pc.hardware.chips Bill Todd <billtodd@metrocast.net>
>>wrote:
>
>
>>>>http://www-106.ibm.com/developerworks/linux/library/l-htl/
>>>>Table 7. 45% geometric mean improvement for handling chat rooms on a
>>>>linux kernel tweaked for Hyperthreading.
>
>
>>>I wonder exactly what it is about that workload that's so
>>>much more HT-friendly than the others (unless it's something
>>>dead-simple like a ridiculously short time quantum per
>>>thread, such that context-switching overheads dominate the
>>>workload and halving them helps a *lot*).
>
>
> The workload is bogus, deliberately designed to inflate the numbers.
>
>
>>Well, IRC does mean ridiculously short timeslices (little work)
>>before a blocking syscall that yields the CPU. Just shovelling
>>data from one port to another.
>
>
>>Also important in this case will be doing useful work during
>>memory latency fetches. The busmaster ethernet devices will
>>drop data into RAM, and some code (probably the kernel TCP/IP
>>stack) will stall loading it into cache.
>
>
> If you look at the way they created the test, the 'chat' test is really
> just a measure of how fast you can do context switches. With HT (and this
> ridiculously unrealistic type of workload), you need half as many context
> switches. Only an idiot would design a chat application such that a context
> switch would be needed every time the server wanted to change which client
> it was working on behalf of.

Okay, enlighten me, how do you handle client requests without a context
switch? Having a thread do a blocking read on a socket actually scales
better than select() on many system (certainly Linux). Let's skip the
writes for a little while until I think about the issues. Having a mix
of slow and fast connections and comments going to multiple clients
makes it worthy of some thought.

Unless I misremember both apache and sendmail use threads just because
of the select scaling issues.

--
-bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me