Sign in with
Sign up | Sign in
Your question

Intel Shelton

Last response: in CPUs
Share
September 4, 2004 1:04:21 AM

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

http://www.hkepc.com/hwdb/intelobc-3.htm

Banias with 0 L2 cache (zero :p ) and 1GHz clock.


Pozdrawiam.
--
RusH //
http://randki.o2.pl/profil.php?id_r=352019
Like ninjas, true hackers are shrouded in secrecy and mystery.
You may never know -- UNTIL IT'S TOO LATE.

More about : intel shelton

Anonymous
a b à CPUs
September 4, 2004 3:12:30 AM

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

RusH wrote:

> http://www.hkepc.com/hwdb/intelobc-3.htm
>
> Banias with 0 L2 cache (zero :p ) and 1GHz clock.

What's the transistor count? Since Intel stripped almost every
transistor, what's left is 64 KB SRAM (~3.5 million) + the core.
I've wondered how complex the Pentium M core was.
Related resources
September 4, 2004 3:12:31 AM

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

Nudge <honeypot@kma.eu.org> wrote :

> RusH wrote:
>
>> http://www.hkepc.com/hwdb/intelobc-3.htm
>>
>> Banias with 0 L2 cache (zero :p ) and 1GHz clock.
>
> What's the transistor count? Since Intel stripped almost every
> transistor, what's left is 64 KB SRAM (~3.5 million) + the core.
> I've wondered how complex the Pentium M core was.

count shmount, AMD XP processor running with 1250MHz and 1.15V works
with passive cooling just fine. And I mean stock AMD XP procesor with
L5 modded (mobilized), 5x250MHz FSB. Intel is backpeddaling.

Pozdrawiam.
--
RusH //
http://randki.o2.pl/profil.php?id_r=352019
Like ninjas, true hackers are shrouded in secrecy and mystery.
You may never know -- UNTIL IT'S TOO LATE.
Anonymous
a b à CPUs
September 4, 2004 10:12:14 AM

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

RusH wrote:
> http://www.hkepc.com/hwdb/intelobc-3.htm
>
> Banias with 0 L2 cache (zero :p ) and 1GHz clock.

So I guess that answers that speculation about whether it was a Pentium 4 or
a Pentium M core.

Yousuf Khan
Anonymous
a b à CPUs
September 6, 2004 4:06:47 AM

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

JK wrote:

> RusH wrote:
>
>> http://www.hkepc.com/hwdb/intelobc-3.htm
>>
>> Banias with 0 L2 cache (zero :p ) and 1GHz clock.
>
> It isn't a 64 bit processor though.

What is your point?
Anonymous
a b à CPUs
September 6, 2004 2:43:43 PM

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

JK wrote:

> [Shelton] isn't a 64 bit processor though.

Isn't Shelton supposed to be dirt cheap?

Let's play guesstimates, give or take 20%. Strip the L2 cache, I call
~30 million transistors. At 90 nm, I'd bet on ~25 mm^2. In other words,
Shelton would be 4.5x smaller than Prescott. Moreover, it's only
supposed to run at 1 GHz, when Dothan scales to 2 GHz. I say Intel would
probably sell Shelton for less than $40.

It was fun making numbers up!
Anonymous
a b à CPUs
September 7, 2004 4:13:14 AM

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

On Fri, 03 Sep 2004 18:42:09 -0400, JK <JK9821@netscape.net> wrote:
>
>RusH wrote:
>
>> http://www.hkepc.com/hwdb/intelobc-3.htm
>>
>> Banias with 0 L2 cache (zero :p ) and 1GHz clock.
>
>It isn't a 64 bit processor though.

Uhh.. given the target market involved here, that is REALLY not an
issue! Even the fact that the performance will kind of stink isn't
such a huge issue for the target market, as the main competitor seems
to be VIA's C3 processor. One of these chips could make a nice base
for a PVR sort of setup (one of my many projects planned for when I'm
not broke!).

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
September 7, 2004 5:05:15 AM

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

Tony Hill wrote:

> On Fri, 03 Sep 2004 18:42:09 -0400, JK <JK9821@netscape.net> wrote:
> >
> >RusH wrote:
> >
> >> http://www.hkepc.com/hwdb/intelobc-3.htm
> >>
> >> Banias with 0 L2 cache (zero :p ) and 1GHz clock.
> >
> >It isn't a 64 bit processor though.
>
> Uhh.. given the target market involved here, that is REALLY not an
> issue!

Perhaps not a big issue this moment, however it will be a much
more important issue after 64 bit Windows is released. Those
with foresight who don't plan to run 64 bit software immediately
realize that they will probably want to run 64 bit software within
around 30-36 months (perhaps the typical amount of time the
average person uses a notebook computer.)

> Even the fact that the performance will kind of stink isn't
> such a huge issue for the target market, as the main competitor seems
> to be VIA's C3 processor.

We haven't seen the specs on the low power Athlon 64 chips yet.


> One of these chips could make a nice base
> for a PVR sort of setup (one of my many projects planned for when I'm
> not broke!).
>
> -------------
> Tony Hill
> hilla <underscore> 20 <at> yahoo <dot> ca
September 7, 2004 5:35:52 PM

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

Intel operates sort of like a phamaceutical company, where its cost to produce
each product doesn't have any direct relationship to its selling price,
especially if
the production cost is very low. It prices the product at what it thinks would
be
optimal for it.

Grumble wrote:

> JK wrote:
>
> > [Shelton] isn't a 64 bit processor though.
>
> Isn't Shelton supposed to be dirt cheap?
>
> Let's play guesstimates, give or take 20%. Strip the L2 cache, I call
> ~30 million transistors. At 90 nm, I'd bet on ~25 mm^2. In other words,
> Shelton would be 4.5x smaller than Prescott. Moreover, it's only
> supposed to run at 1 GHz, when Dothan scales to 2 GHz. I say Intel would
> probably sell Shelton for less than $40.
>
> It was fun making numbers up!
Anonymous
a b à CPUs
September 8, 2004 7:02:30 AM

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

On Tue, 07 Sep 2004 01:05:15 -0400, JK <JK9821@netscape.net> wrote:
>Tony Hill wrote:
>
>> On Fri, 03 Sep 2004 18:42:09 -0400, JK <JK9821@netscape.net> wrote:
>> >
>> >RusH wrote:
>> >
>> >> http://www.hkepc.com/hwdb/intelobc-3.htm
>> >>
>> >> Banias with 0 L2 cache (zero :p ) and 1GHz clock.
>> >
>> >It isn't a 64 bit processor though.
>>
>> Uhh.. given the target market involved here, that is REALLY not an
>> issue!
>
>Perhaps not a big issue this moment, however it will be a much
>more important issue after 64 bit Windows is released. Those
>with foresight who don't plan to run 64 bit software immediately
>realize that they will probably want to run 64 bit software within
>around 30-36 months (perhaps the typical amount of time the
>average person uses a notebook computer.)

You or I might, but you or I are NOT the target market for this
processor, not in the least. The real key benefit that 64-bit code
buys you is the ability to use more than 4GB of memory at a time, but
for the sort of low-end systems that this is targeting that is a TOTAL
non-issue for the next 5+ years at a minimum!

>> Even the fact that the performance will kind of stink isn't
>> such a huge issue for the target market, as the main competitor seems
>> to be VIA's C3 processor.
>
>We haven't seen the specs on the low power Athlon 64 chips yet.

Low-power Athlon64 chips I've seen have been in the 25-35W range,
these chips are likely to be down in the 7-10W range. That's quite a
difference.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
September 8, 2004 1:44:13 PM

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

It isn't just the ability to run more than 4 gigs of ram. Here is one example
where
the 64 bit version of the software finishes a task 25% faster than the 32 bit
version.

http://www.short-media.com/review.php?r=257&p=2

In the future we will probably see differences of much greater than 25%
for some applications.

Tony Hill wrote:

> On Tue, 07 Sep 2004 01:05:15 -0400, JK <JK9821@netscape.net> wrote:
> >Tony Hill wrote:
> >
> >> On Fri, 03 Sep 2004 18:42:09 -0400, JK <JK9821@netscape.net> wrote:
> >> >
> >> >RusH wrote:
> >> >
> >> >> http://www.hkepc.com/hwdb/intelobc-3.htm
> >> >>
> >> >> Banias with 0 L2 cache (zero :p ) and 1GHz clock.
> >> >
> >> >It isn't a 64 bit processor though.
> >>
> >> Uhh.. given the target market involved here, that is REALLY not an
> >> issue!
> >
> >Perhaps not a big issue this moment, however it will be a much
> >more important issue after 64 bit Windows is released. Those
> >with foresight who don't plan to run 64 bit software immediately
> >realize that they will probably want to run 64 bit software within
> >around 30-36 months (perhaps the typical amount of time the
> >average person uses a notebook computer.)
>
> You or I might, but you or I are NOT the target market for this
> processor, not in the least. The real key benefit that 64-bit code
> buys you is the ability to use more than 4GB of memory at a time, but
> for the sort of low-end systems that this is targeting that is a TOTAL
> non-issue for the next 5+ years at a minimum!
>
> >> Even the fact that the performance will kind of stink isn't
> >> such a huge issue for the target market, as the main competitor seems
> >> to be VIA's C3 processor.
> >
> >We haven't seen the specs on the low power Athlon 64 chips yet.
>
> Low-power Athlon64 chips I've seen have been in the 25-35W range,
> these chips are likely to be down in the 7-10W range. That's quite a
> difference.
>
> -------------
> Tony Hill
> hilla <underscore> 20 <at> yahoo <dot> ca
Anonymous
a b à CPUs
September 9, 2004 7:35:44 AM

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

On Wed, 08 Sep 2004 09:44:13 -0400, JK <JK9821@netscape.net> wrote:

>It isn't just the ability to run more than 4 gigs of ram. Here is one example
>where
>the 64 bit version of the software finishes a task 25% faster than the 32 bit
>version.

And given that the target market for these chips has absolutely ZERO
to do with performance, how does this help exactly?

>In the future we will probably see differences of much greater than 25%
>for some applications.

In some very rare situations, yes. In fact, it's not at all difficult
to show a 100% improvement when going from 32-bit to 64-bit, but
that's definitely not the norm. Average is, and will continue to be,
about 5%, and some applications will always be slower as 64-bit apps
than 32-bit ones.

Still, as mentioned above, the target market for this chip is NOT
looking at performance, so a small improvement is totally meaningless.
If anyone cared about a 25% improvement in performance they wouldn't
even be considering this "Shelton" chip in the first place!

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
September 9, 2004 2:23:11 PM

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

Tony Hill wrote:

> On Wed, 08 Sep 2004 09:44:13 -0400, JK <JK9821@netscape.net> wrote:
>
> >It isn't just the ability to run more than 4 gigs of ram. Here is one example
> >where
> >the 64 bit version of the software finishes a task 25% faster than the 32 bit
> >version.
>
> And given that the target market for these chips has absolutely ZERO
> to do with performance, how does this help exactly?
>
> >In the future we will probably see differences of much greater than 25%
> >for some applications.
>
> In some very rare situations, yes. In fact, it's not at all difficult
> to show a 100% improvement when going from 32-bit to 64-bit, but
> that's definitely not the norm.

i'm not talkking about 32 bit software on a 64 bit OS, which still might show a
performance increase of 10-20% or more in some instances, I am talking
about 64 bit applications. Anything that does complex calculations will
be much faster with 64 bit software.

> Average is, and will continue to be,
> about 5%

Not quite. Average might be 40% or more. We will have to see.

> , and some applications will always be slower as 64-bit apps

How can a well written 64 bit application be slower than its 32 bit version
on an Opteron or Athlon 64?

>
> than 32-bit ones.
>
> Still, as mentioned above, the target market for this chip is NOT
> looking at performance, so a small improvement is totally meaningless.
> If anyone cared about a 25% improvement in performance

25% faster execution is extremely important.It is a 33% performance improvement.
On desktop systems, to get that performance boost
one might have to choose a 3.6 ghz Pentium 4 instead of a 2.4 ghz one.
That would mean buying a cpu that is four times the price of the other.



> they wouldn't
> even be considering this "Shelton" chip in the first place!
>
> -------------
> Tony Hill
> hilla <underscore> 20 <at> yahoo <dot> ca
Anonymous
a b à CPUs
September 9, 2004 7:30:57 PM

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

JK <JK9821@netscape.net> wrote:
> i'm not talkking about 32 bit software on a 64 bit OS, which
> still might show a performance increase of 10-20% or more in some
> instances, I am talking about 64 bit applications. Anything that
> does complex calculations will be much faster with 64 bit software.

It depends on the calcs! Many, many complex calcs use
floating point. SSE2 helps. 64 bit does not in the
slightest. A lot of image processing uses 32bit pixels
and probably won't see much either.

OTOH, compression and encryption deal with bit-strings
and will see considerable (maybe 2x) improvement.

> How can a well written 64 bit application be slower than
> its 32 bit version on an Opteron or Athlon 64?

Larger code-size! Once-thru code takes much longer to fetch
than execute (longer still if you include disk!) RISC People
complain about x86 having a quirky asymmetical instruction set.
It does. The advantage is code density.

> 25% faster execution is extremely important.

Uhm ... for whom doing what? You must have been miserable
with a 4.77 MHz 8088 (original IBM PC & XT).

The PC biz has been a vicitim of success. Ever fewer people
notice major improvements with CPU speed. Other things,
like broadband, OS & disk limit. Even the gamers are now
more interested in video card performance.

-- Robert
September 9, 2004 7:30:58 PM

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

Robert Redelmeier wrote:

> JK <JK9821@netscape.net> wrote:
> > i'm not talkking about 32 bit software on a 64 bit OS, which
> > still might show a performance increase of 10-20% or more in some
> > instances, I am talking about 64 bit applications. Anything that
> > does complex calculations will be much faster with 64 bit software.
>
> It depends on the calcs! Many, many complex calcs use
> floating point. SSE2 helps. 64 bit does not in the
> slightest. A lot of image processing uses 32bit pixels
> and probably won't see much either.
>
> OTOH, compression and encryption deal with bit-strings
> and will see considerable (maybe 2x) improvement.
>
> > How can a well written 64 bit application be slower than
> > its 32 bit version on an Opteron or Athlon 64?
>
> Larger code-size! Once-thru code takes much longer to fetch
> than execute (longer still if you include disk!) RISC People
> complain about x86 having a quirky asymmetical instruction set.
> It does. The advantage is code density.
>
> > 25% faster execution is extremely important.
>
> Uhm ... for whom doing what? You must have been miserable
> with a 4.77 MHz 8088 (original IBM PC & XT).
>
> The PC biz has been a vicitim of success. Ever fewer people
> notice major improvements with CPU speed. Other things,
> like broadband, OS & disk limit. Even the gamers are now
> more interested in video card performance.

To some degree, but without a fast cpu, even the highest end graphics
card will be held back. Look at these Doom 3 results for example.

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=214...

>
>
> -- Robert
Anonymous
a b à CPUs
September 9, 2004 10:31:13 PM

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

Robert Redelmeier wrote:
> JK <JK9821@netscape.net> wrote:
>
>>i'm not talkking about 32 bit software on a 64 bit OS, which
>>still might show a performance increase of 10-20% or more in some
>>instances, I am talking about 64 bit applications. Anything that
>>does complex calculations will be much faster with 64 bit software.
>
>
> It depends on the calcs! Many, many complex calcs use
> floating point. SSE2 helps. 64 bit does not in the
> slightest. A lot of image processing uses 32bit pixels
> and probably won't see much either.

If it helps any I saw 6x speed bump when doing bitplane
bashing when I rewrite some code to do it in 8x8 chunks
(ie: 64bit)...

Also a lot of algorithms can probably use 64bit ints
*intead* of floats. I've seen a lot of folks use floats
as 54bit ints (and that is a --ing stupid thing to do
IMO)... People have applied 64bit fixed point to 3D
graphics before too (although I *doubt* this will happen
given the APIs around at the moment).

Folks might find 64bit ints handy for hashing too.

> OTOH, compression and encryption deal with bit-strings
> and will see considerable (maybe 2x) improvement.
>
>
>>How can a well written 64 bit application be slower than
>>its 32 bit version on an Opteron or Athlon 64?
>
>
> Larger code-size! Once-thru code takes much longer to fetch
> than execute (longer still if you include disk!) RISC People
> complain about x86 having a quirky asymmetical instruction set.
> It does. The advantage is code density.

There's plenty of bandwidth and cache for instruction
streams now. It's not the problem it was.

Cheers,
Rupert
Anonymous
a b à CPUs
September 9, 2004 10:31:14 PM

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

Rupert Pigott <roo@try-removing-this.darkboong.demon.co.uk> wrote:
> If it helps any I saw 6x speed bump when doing bitplane
> bashing when I rewrite some code to do it in 8x8 chunks
> (ie: 64bit)...

6x comparing 8x to 4x4 or 1x1?

> Also a lot of algorithms can probably use 64bit ints
> *intead* of floats.

First they will need to decide on an appropriate scale factor.
Many of these problems are from engineering, with continuous
variables. The algorithms are also sometimes very intolerant
of underflow to zero (Eigenvalues). I very much doubt anyone
is going to move away from FP, especially since the math ops
are basically the same speed.

> I've seen a lot of folks use floats as 54bit
> ints (and that is a --ing stupid thing to do IMO

Why, if their numbers will fit into 54 bit DP floats? Easier
to do accountancy in DP floats when it won't fit into 32 bits.

-- Robert
Anonymous
a b à CPUs
September 9, 2004 11:56:20 PM

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

Robert Redelmeier wrote:

> Rupert Pigott <roo@try-removing-this.darkboong.demon.co.uk> wrote:
>
>>If it helps any I saw 6x speed bump when doing bitplane
>>bashing when I rewrite some code to do it in 8x8 chunks
>>(ie: 64bit)...
>
>
> 6x comparing 8x to 4x4 or 1x1?
>
>
>>Also a lot of algorithms can probably use 64bit ints
>>*intead* of floats.
>
>
> First they will need to decide on an appropriate scale factor.

Uhuh, it is doable believe it or not.

> Many of these problems are from engineering, with continuous
> variables. The algorithms are also sometimes very intolerant

I'd dispute "many".

> of underflow to zero (Eigenvalues). I very much doubt anyone
> is going to move away from FP, especially since the math ops
> are basically the same speed.

Utilising FP and Int units at full whack can improve
throughput.

One example of that was implementing the naive line drawing
algorithm on a particular processor instead of Bressenham.
With the naive one the int side of the core did all the
address calc while the FP side of the core got on an worked
out where the next point was gonna be. Overlapped nicely and
got a big speed boost. :) 

>>I've seen a lot of folks use floats as 54bit
>>ints (and that is a --ing stupid thing to do IMO
>
>
> Why, if their numbers will fit into 54 bit DP floats? Easier
> to do accountancy in DP floats when it won't fit into 32 bits.

Also very wrong when it comes to some rounding issues. How do
you detect if you've lost a few pennies here and there ? Not
that this bothered the people in question because it wasn't
their money in the accounts. ;) 

Cheers,
Rupert
Anonymous
a b à CPUs
September 10, 2004 12:17:36 AM

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

Rupert Pigott <roo@try-removing-this.darkboong.demon.co.uk> wrote:
> Uhuh, it is doable believe it or not.

Yes, it _is_ do-able, but correct scale factors aren't obvious.
Iv'e done fixed-point work in the 80s when machines just didn't have
the power. About as much fun as programming analog computers.

> I'd dispute "many".

Please! Finite-element calculations of all kinds (from weather
to nuclear weapons design) have eaten and continue to eat huge
numbers of CPU cycles. Perhaps more than any other single class
of app except the idle thread (games?). We use them for reservoir
engineering and fluid dynamics. We've just finished building a
second Linux cluster (16 dual Xeons). Some jobs take overnight.

> Utilising FP and Int units at full whack can improve
> throughput.

Sometimes, but only if they're separate and you can load
them both. The P7 (Pentium4) only has one multiplier :( 

> Also very wrong when it comes to some rounding issues.

Of course! Why do you think there's an IEEE on FP calcs?
x87 arch has plenty of control on rounding, and extra guard
bits too! The real problem is `c`, especially the truncation
it loves to do on output.

> How do you detect if you've lost a few pennies here and
> there? Not that this bothered the people in question
> because it wasn't their money in the accounts. ;) 

Standard accounting double-entry bookkeeping!

-- Robert
September 10, 2004 2:48:12 AM

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

On Thu, 09 Sep 2004 20:17:36 +0000, Robert Redelmeier wrote:

> Rupert Pigott <roo@try-removing-this.darkboong.demon.co.uk> wrote:
>> Uhuh, it is doable believe it or not.
>
> Yes, it _is_ do-able, but correct scale factors aren't obvious.
> Iv'e done fixed-point work in the 80s when machines just didn't have
> the power. About as much fun as programming analog computers.

Come on Robert! There is nothing as facinating as analog computers. Ah,
I learned to program the PACE beauties (kabillion tubes, servo
multipliers/sine_converters, and patch panels) in college and then was
"sentenced" to maintaining them every summer. You see I was the only one
who knew how they worked. (Hint: the AC in the analog computer lab beat
anything else on campus ;-) Of course scaling such beasties requires
more then a little graps of calc, but... ;-)

>> I'd dispute "many".
>
> Please! Finite-element calculations of all kinds (from weather to
> nuclear weapons design) have eaten and continue to eat huge numbers of
> CPU cycles. Perhaps more than any other single class of app except the
> idle thread (games?). We use them for reservoir engineering and fluid
> dynamics. We've just finished building a second Linux cluster (16 dual
> Xeons). Some jobs take overnight.

....and there is no use for 64b scalars? Perhaps your code doesn't *yet*
work, but 2^64 is a rather big number. ...place the BP where you wish.

I'm sure a few more registers would help some too.

>> Utilising FP and Int units at full whack can improve throughput.
>
> Sometimes, but only if they're separate and you can load them both. The
> P7 (Pentium4) only has one multiplier :( 

Well, damn! It seems you made a poor choice of processors then, eh? ;-)
This ilittle fact is rather well known (add the lack of the
barrel-shifter). Perhaps you really *should* have bought Opterons.

>> Also very wrong when it comes to some rounding issues.
>
> Of course! Why do you think there's an IEEE on FP calcs? x87 arch has
> plenty of control on rounding, and extra guard bits too! The real
> problem is `c`, especially the truncation it loves to do on output.

Umm, you said you use P4's. What about de-norms?

>> How do you detect if you've lost a few pennies here and there? Not that
>> this bothered the people in question because it wasn't their money in
>> the accounts. ;) 
>
> Standard accounting double-entry bookkeeping!

Nope, you use BCD arithmetic. Anyone using floats for financial
calculations is simply nutz! FWIG, floats are prohibited by FASB. At
least that's what they told us some years ago when I took a PL/I course
(and stared in wonderment at the packed BCD arithmetic). You know, the
ol' trunction into *my* account sort of thing. Perhaps someone in the
financial biz can correct me.

--
Keith
Anonymous
a b à CPUs
September 10, 2004 8:39:36 AM

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

On Thu, 09 Sep 2004 10:23:11 -0400, JK <JK9821@netscape.net> wrote:
>Tony Hill wrote:
>
>> On Wed, 08 Sep 2004 09:44:13 -0400, JK <JK9821@netscape.net> wrote:
>>
>> >It isn't just the ability to run more than 4 gigs of ram. Here is one example
>> >where
>> >the 64 bit version of the software finishes a task 25% faster than the 32 bit
>> >version.
>>
>> And given that the target market for these chips has absolutely ZERO
>> to do with performance, how does this help exactly?
>>
>> >In the future we will probably see differences of much greater than 25%
>> >for some applications.
>>
>> In some very rare situations, yes. In fact, it's not at all difficult
>> to show a 100% improvement when going from 32-bit to 64-bit, but
>> that's definitely not the norm.
>
>i'm not talkking about 32 bit software on a 64 bit OS, which still might show a
>performance increase of 10-20% or more in some instances,

Under extreme situations maybe, but generally speaking 32-bit apps on
a 64-bit OS will see absolutely no improvement at all.

> I am talking
>about 64 bit applications. Anything that does complex calculations will
>be much faster with 64 bit software.

That depends entirely on what the calculations are doing. If they
need integer calculations that require a range of more than 4 billion,
then yes, they will be considerably faster (that was the 100%
improvement I was referring to above). Basically all other
calculations will see absolutely no difference at all from the
64-bitness, though the extra registers might give you a bit of a boost
(usually about 5%). Doing complex calculations with floating point
code won't give you any improvement at all, nor SSE or MMX code.

>> Average is, and will continue to be,
>> about 5%
>
>Not quite. Average might be 40% or more. We will have to see.

Keep dreaming!

>> , and some applications will always be slower as 64-bit apps
>
>How can a well written 64 bit application be slower than its 32 bit version
>on an Opteron or Athlon 64?

VERY easily! 64-bit code = 64-bit pointers, and guess what? Those
are twice as big as 32-bit pointers! Twice as big means you have
effectively half as much bandwidth and cache space to shuffle those
pointers around in.

If all else were equal, 64-bit code is usually about 5-10% SLOWER than
32-bit code. This is a well known fact and has been demonstrated on
SPARC and PowerPC at the very least. The only reason why AMD64 code
isn't usually slower is that AMD also doubled the number of integer
registers in the chip. This helps counteract the performance loss
associated with 64-bit code and actually means that it's usually a
little bit faster, usually about 5%.

>> than 32-bit ones.
>>
>> Still, as mentioned above, the target market for this chip is NOT
>> looking at performance, so a small improvement is totally meaningless.
>> If anyone cared about a 25% improvement in performance
>
>25% faster execution is extremely important.It is a 33% performance improvement.

Uhhh... that's some funny math you're doing there! Or at best some
funny wording of things.

>On desktop systems, to get that performance boost
>one might have to choose a 3.6 ghz Pentium 4 instead of a 2.4 ghz one.
>That would mean buying a cpu that is four times the price of the other.

Now you're math is getting even funnier... not to mention the fact
that we're not talking about top-end processors but rather an extreme
low-cost chip for developing markets!

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
Anonymous
a b à CPUs
September 10, 2004 10:03:50 AM

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

keith <krw@att.bizzzz> wrote:
> Come on Robert! There is nothing as facinating as analog
> computers. Ah, I learned to program the PACE beauties (kabillion
> tubes, servo multipliers/sine_converters, and patch panels)

Granted, they were fascinating. Especially to watch a pgm
"run" once you got everything scaled right.

> ...and there is no use for 64b scalars? Perhaps your
> code doesn't *yet* work, but 2^64 is a rather big number.
> ...place the BP where you wish.

Well, there's a lot more room for error :) 

> I'm sure a few more registers would help some too.

I think this is a canard. x86 has blazing fast L1 and
a decent scheduler to bury the latency. It doesn't need
more registers. Just more to save/restore on context switch.

> Well, damn! It seems you made a poor choice of processors

Not my choice of hardware :( 

> Umm, you said you use P4's. What about de-norms?

Haven't been a problem. The algorithm's are quite robust,
just take a long while to settle down.

> Nope, you use BCD arithmetic. Anyone using floats for financial
> calculations is simply nutz! FWIG, floats are prohibited by FASB.

Once upon a time, I'd've agreed. But FP has improved a
great deal with IEEE 754. x87 even has `fbld` and `fbst`
instructions to load/sto 18digit BCDs.

> At least that's what they told us some years ago when I
> took a PL/I course (and stared in wonderment at the packed BCD
> arithmetic). You know, the ol' trunction into *my* account sort
> of thing. Perhaps someone in the financial biz can correct me.

It would be interesting. I might wander 'a googling.

-- Robert
September 10, 2004 2:52:10 PM

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

On Fri, 10 Sep 2004 06:03:50 +0000, Robert Redelmeier wrote:

> keith <krw@att.bizzzz> wrote:
>
>> I'm sure a few more registers would help some too.
>
> I think this is a canard. x86 has blazing fast L1 and
> a decent scheduler to bury the latency. It doesn't need
> more registers. Just more to save/restore on context switch.

So, your position is that eight FX registers is enough? What about the
SSE register file? RISC processor architects tend to disagree, even with
fast caches.

--
Keith
Anonymous
a b à CPUs
September 10, 2004 3:40:27 PM

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

Robert Redelmeier wrote:
> keith <krw@att.bizzzz> wrote:
>
>>Come on Robert! There is nothing as facinating as analog
>>computers. Ah, I learned to program the PACE beauties (kabillion
>>tubes, servo multipliers/sine_converters, and patch panels)
>
>
> Granted, they were fascinating. Especially to watch a pgm
> "run" once you got everything scaled right.
>
>
>>...and there is no use for 64b scalars? Perhaps your
>>code doesn't *yet* work, but 2^64 is a rather big number.
>>...place the BP where you wish.
>
>
> Well, there's a lot more room for error :) 

In the case of overflow : Quite the reverse. I see overflow
in 32bit ints quite frequently. People are making 2+G files
now too, which frequently causes 32bit code to blow up when
it tries to access said files... Plenty of numnutz 32bit
code out there.;)

>>I'm sure a few more registers would help some too.
>
>
> I think this is a canard. x86 has blazing fast L1 and
> a decent scheduler to bury the latency. It doesn't need
> more registers. Just more to save/restore on context switch.

It also has HT because it can't bury the latency that well.

>>Well, damn! It seems you made a poor choice of processors
>
>
> Not my choice of hardware :( 
>
>
>>Umm, you said you use P4's. What about de-norms?
>
>
> Haven't been a problem. The algorithm's are quite robust,
> just take a long while to settle down.
>
>
>>Nope, you use BCD arithmetic. Anyone using floats for financial
>>calculations is simply nutz! FWIG, floats are prohibited by FASB.
>
>
> Once upon a time, I'd've agreed. But FP has improved a
> great deal with IEEE 754. x87 even has `fbld` and `fbst`
> instructions to load/sto 18digit BCDs.

Not applicable to *real* "has to be correct" code apparently.
There is a thread in afc about that right now. ;) 

>>At least that's what they told us some years ago when I
>>took a PL/I course (and stared in wonderment at the packed BCD
>>arithmetic). You know, the ol' trunction into *my* account sort
>>of thing. Perhaps someone in the financial biz can correct me.
>
>
> It would be interesting. I might wander 'a googling.

Trust me : It caused problems, I worked at a bank when I first
came across that rather dubious hack.

Cheers,
Rupert
Anonymous
a b à CPUs
September 10, 2004 4:28:14 PM

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

Tony Hill wrote:

> Basically all other calculations will see absolutely no difference at
> all from the 64-bitness, though the extra registers might give you a
> bit of a boost (usually about 5%). Doing complex calculations with
> floating point code won't give you any improvement at all, nor SSE or
> MMX code.

AMD64 also doubled the number of media (XMM) registers. Thus SIMD code
might see an improvement, wouldn't you agree?

--
Regards, Grumble
Anonymous
a b à CPUs
September 10, 2004 6:11:15 PM

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

Rupert Pigott <roo@try-removing-this.darkboong.demon.co.uk> wrote:
>> Well, there's a lot more room for error :) 
>
> In the case of overflow : Quite the reverse. I see overflow
> in 32bit ints quite frequently. People are making 2+G files

I was referring to error in fixed point placement. There's a
lot more room for error with 64 bit ints than 32.

> It also has HT because it can't bury the latency that well.

For DRAM latency, not L1 cache latency.

> Not applicable to *real* "has to be correct" code apparently.
> There is a thread in afc about that right now. ;) 

I'm not familiar -- what is afc?

> Trust me : It caused problems, I worked at a bank when I first
> came across that rather dubious hack.

Of course it can cause problems. Anything can if carelessly
done. Nothing is foolproof -- fools are too d@mned ingenious!

The real question is whether it can be done correctly
by sufficiently knowledgeable people. The people
who failed will always try to blame something else.

-- Robert
September 10, 2004 6:11:16 PM

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

On Fri, 10 Sep 2004 14:11:15 +0000, Robert Redelmeier wrote:

> Rupert Pigott <roo@try-removing-this.darkboong.demon.co.uk> wrote:
>>> Well, there's a lot more room for error :) 
>>
>> In the case of overflow : Quite the reverse. I see overflow
>> in 32bit ints quite frequently. People are making 2+G files
>
> I was referring to error in fixed point placement. There's a
> lot more room for error with 64 bit ints than 32.

Huh??

<snip>

>> Not applicable to *real* "has to be correct" code apparently.
>> There is a thread in afc about that right now. ;) 
>
> I'm not familiar -- what is afc?

alt.folklore.computers

>> Trust me : It caused problems, I worked at a bank when I first
>> came across that rather dubious hack.
>
> Of course it can cause problems. Anything can if carelessly
> done. Nothing is foolproof -- fools are too d@mned ingenious!
>
> The real question is whether it can be done correctly
> by sufficiently knowledgeable people. The people
> who failed will always try to blame something else.

Again, it's my understanding that accounting rules specify fixed-point
decimal arithmetic to the precision of the computer. This is to eliminate
bin/dec conversion errors and rounding biases. Things may have changed
over the past 20ish years though.

--
Keith
Anonymous
a b à CPUs
September 11, 2004 2:42:06 AM

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

keith <krw@att.bizzzz> wrote:
>> I was referring to error in fixed point placement. There's a
>> lot more room for error with 64 bit ints than 32.
>
> Huh??

If you're using fixed-point arithmetic instead of floats,
the real question is to find a scale factor that won't cause
trouble (underflow to zero, overflows) during intermediate
calcs. Much more room to find such a factor in 64 bits and
a decade or two error in the factor is more likely to work.

> Again, it's my understanding that accounting rules specify
> fixed-point decimal arithmetic to the precision of the computer.

No multiple-precision? So no accountancy on 16bit machines
since the machine word will only hold $327.68?

> This is to eliminate bin/dec conversion errors and
> rounding biases.

bin/dec conversion is precise for integers. Decimals are
not, that's why accountancy is done in cents, not dollars.
Rounding is a whole different subject, but has to be done any
time there is division (or multiplication by a non-integer).
BCD still has to round, one way or the other.

> Things may have changed over the past 20ish years though.

Understood. Worth checking the state-of-the-art.

-- Robert
September 11, 2004 3:42:38 AM

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

On Fri, 10 Sep 2004 22:42:06 +0000, Robert Redelmeier wrote:

> keith <krw@att.bizzzz> wrote:
>>> I was referring to error in fixed point placement. There's a
>>> lot more room for error with 64 bit ints than 32.
>>
>> Huh??
>
> If you're using fixed-point arithmetic instead of floats,
> the real question is to find a scale factor that won't cause
> trouble (underflow to zero, overflows) during intermediate
> calcs. Much more room to find such a factor in 64 bits and
> a decade or two error in the factor is more likely to work.

FOr most calculations 2W64 is a big number. The number of particles in
the universe is on the order of 1E90, so we're in shootin' range. Think
wisely, grasshopper. ;-)

>> Again, it's my understanding that accounting rules specify fixed-point
>> decimal arithmetic to the precision of the computer.
>
> No multiple-precision? So no accountancy on 16bit machines since the
> machine word will only hold $327.68?

IIRC the 360 packed-BCD arithmetic was 15bytes-30 significant digits.
$1E28 will even cover the national debt for a year or two more.

>> This is to eliminate bin/dec conversion errors and rounding biases.
>
> bin/dec conversion is precise for integers.

Think interest calculations.

> Decimals are not

If you do arithmetic in decimal, there is no conversion error. That's the
point.

> that's why accountancy is done in cents, not dollars.

Irrlevant (I beliueve it's done in mills, but...). The point is that
there is no "leakage" during conversions, if there are no conversions.
....rounding is "fair".

> Rounding is a whole
> different subject, but has to be done any time there is division (or
> multiplication by a non-integer). BCD still has to round, one way or the
> other.

The point is that it's *fair*. The "house' winsas often as it
loses. There is no leakage.

>> Things may have changed over the past 20ish years though.
>
> Understood. Worth checking the state-of-the-art.

Let us know. I have no idea what to search here. As was pointed out
before, this was discussed on AFC, but there didn't seem to be any
financial IT types over there at the time.

--
Keith
Anonymous
a b à CPUs
September 11, 2004 6:42:24 AM

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

On Fri, 10 Sep 2004 12:28:14 +0200, Grumble <devnull@kma.eu.org>
wrote:
>
>Tony Hill wrote:
>
>> Basically all other calculations will see absolutely no difference at
>> all from the 64-bitness, though the extra registers might give you a
>> bit of a boost (usually about 5%). Doing complex calculations with
>> floating point code won't give you any improvement at all, nor SSE or
>> MMX code.
>
>AMD64 also doubled the number of media (XMM) registers. Thus SIMD code
>might see an improvement, wouldn't you agree?

Yes, I suppose so, though this is likely to be even less than the 5%
seen on your average application using the integer registers.

The moral of the story though is simply not to expect speed
improvements from 64-bit code. The fact that AMD64 manages to negate
the usual loss in performance associated with 64-bit code is enough,
but people really shouldn't get their hopes up for big improvements.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
Anonymous
a b à CPUs
September 11, 2004 9:37:45 PM

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

keith <krw@att.bizzzz> wrote:
> FOr most calculations 2W64 is a big number. The number of
> particles in the universe is on the order of 1E90, so we're
> in shootin' range. Think wisely, grasshopper. ;-)

1e90 ~= 2^300, and there's a lot more information than
simply the number of particles.

>> bin/dec conversion is precise for integers.
> Think interest calculations.

Of course. But interest rates aren't integers!
They're usually horrible decimal fractions.

> If you do arithmetic in decimal, there is no conversion
> error. That's the point.

OK, what is 1.5% interest on $1.00 ? Or 1% on $1.50.
Rounding is inevitable.

> ...rounding is "fair".

So select x87 round to nearest or even.
Not the `c` default.

> Let us know. I have no idea what to search here.

It will take a while, `cuz I've got to go
out of country :( 

-- Robert
Anonymous
a b à CPUs
September 11, 2004 10:47:21 PM

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

Robert Redelmeier wrote:

> keith <krw@att.bizzzz> wrote:
>
>>FOr most calculations 2W64 is a big number. The number of
>>particles in the universe is on the order of 1E90, so we're
>>in shootin' range. Think wisely, grasshopper. ;-)
>

1E90 didn't mean much to me, so I tried to put it
into perspective using the proton mass as the average
particle mass ...

1E90 x 1.7 E-27 kg = 1.7 E 63 kg
~ 1 E 33 Solar masses
~ 7 George Foreman
September 14, 2004 2:38:41 AM

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

On Sat, 11 Sep 2004 17:37:45 +0000, Robert Redelmeier wrote:

> keith <krw@att.bizzzz> wrote:
>> FOr most calculations 2W64 is a big number. The number of
>> particles in the universe is on the order of 1E90, so we're
>> in shootin' range. Think wisely, grasshopper. ;-)
>
> 1e90 ~= 2^300, and there's a lot more information than
> simply the number of particles.

Sure, but I like to show how small the universe is. ;-) Have you ever
seen the (IBM produced, IIRC) filmlet "The Power of Ten"?
>
>>> bin/dec conversion is precise for integers.
>> Think interest calculations.
>
> Of course. But interest rates aren't integers! They're usually horrible
> decimal fractions.

Irrelevant. They're expressed as decimal numbers, and the calculations
must be done in decimal, with the rounding done to machine specifications.
At least that's why I'm told that BCD arithmetic was kept in the
mainframes. The 360 types seemed to agree, over on AFC.

>> If you do arithmetic in decimal, there is no conversion error. That's
>> the point.
>
> OK, what is 1.5% interest on $1.00 ? Or 1% on $1.50. Rounding is
> inevitable.

Ok, bot there are no conversions. ROunding is inevitable if you have
green eyeshades too. ...the rounding is *identical*, and that's the
point (at the end of the pencil).
>
>> ...rounding is "fair".
>
> So select x87 round to nearest or even. Not the `c` default.

....even with the Pentium bug? ;-) Again, I'm only reporting what I've
been told. I'm not a financial type. Some where I work are rather tight
this way though. ;-)

>> Let us know. I have no idea what to search here.
>
> It will take a while, `cuz I've got to go out of country :( 

Good travels, and good luck. Google is world-wide though. ;-)

Why the frown?

--
Keith
Anonymous
a b à CPUs
September 22, 2004 10:26:27 PM

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

keith <krw@att.bizzzz> wrote:
> Have you ever seen the (IBM produced, IIRC) filmlet "The
> Power of Ten"?

Nope. Got an MPEG? :) 

> Irrelevant. They're expressed as decimal numbers, and the
> calculations must be done in decimal, with the rounding
> done to machine specifications. At least that's why

It gets much more interesting with the Euro conversion,
and six place conversion factors. Round off accounts were
kept for auditing.

> I'm told that BCD arithmetic was kept in the mainframes.
> The 360 types seemed to agree, over on AFC.

And the x87 also has BCD data types. Single precision floats
are obviously unsuitable for accountancy -- they can only
hold 24 bits, $167,722.16 as whole cents. Double precision
(53 bits) is better, 90 trillion, which is enough for most uses.
Really big things (financial turnover flows) might need more,
and the 64+ bits internally on the x87 meets almost all needs.

The key is that FP on integers (within the precision range)
is just as precise as BCD. Both have equivalent problems
in rounding non-integers, and both get the nines disease.

> Good travels, and good luck. Google is world-wide though.

I've searched high and low (especially fasb. aicpa. acm. and
IEEE.org) and not found any clear prohibition against using
floating point, or even any credible references there is one.
Ultimately, the accountant is responsible for all calcs s/he
signs off for, and FP error is only one cause of error.

> Why the frown?

I don't much like travel. Takes me away from the family.

-- Robert
Anonymous
a b à CPUs
September 23, 2004 1:26:01 PM

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

In article <ntj4d.450$q67.287@newssvr11.news.prodigy.com>,
redelm@ev1.net.invalid says...
> keith <krw@att.bizzzz> wrote:
> > Have you ever seen the (IBM produced, IIRC) filmlet "The
> > Power of Ten"?
>
> Nope. Got an MPEG? :) 

Nah. I first saw it in grade school (about the time the wheel was
invented ;-) and have seen it hundreds of times since though. The last
time was at the Smithsonian (or was it the National History Museum?),
Iperhaps ten years ago. Here's a web site that's sorta the same thing
as the movie, though without the starship. ;-)

http://microcosm.web.cern.ch/microcosm/P10/english/P7.h...

<snip interest calculation discussion - no more info to add>

> > Good travels, and good luck. Google is world-wide though.
>
> I've searched high and low (especially fasb. aicpa. acm. and
> IEEE.org) and not found any clear prohibition against using
> floating point, or even any credible references there is one.
> Ultimately, the accountant is responsible for all calcs s/he
> signs off for, and FP error is only one cause of error.
>
> > Why the frown?
>
> I don't much like travel. Takes me away from the family.

Ah, I didn't realize it was business. I understand.

--
Keith
Anonymous
a b à CPUs
September 23, 2004 6:18:16 PM

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

Keith R. Williams <krw@att.bizzzz> wrote:
> Nah. I first saw it in grade school (about the time the wheel was

Hmm ... you must be a baby. The Eames "Powers of Ten" movie
was dated 1978.

> invented ;-) and have seen it hundreds of times since though. The last
> time was at the Smithsonian (or was it the National History Museum?),
> Iperhaps ten years ago. Here's a web site that's sorta the same thing
> as the movie, though without the starship. ;-)
>
> http://microcosm.web.cern.ch/microcosm/P10/english/P7.h...

Oh, this. There's also a nice series at
http://www.powersoften.com

The decades where things don't change much are interesting.
Odd how information clusters.

-- Robert
Anonymous
a b à CPUs
September 23, 2004 6:19:02 PM

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

In article <IWA4d.13166$yp2.5710@newssvr30.news.prodigy.com>,
redelm@ev1.net.invalid says...
> Keith R. Williams <krw@att.bizzzz> wrote:
> > Nah. I first saw it in grade school (about the time the wheel was
>
> Hmm ... you must be a baby. The Eames "Powers of Ten" movie
> was dated 1978.

Well I just turned "34" on Sunday. ;-) We're obviously talking about
a different movie.

> > invented ;-) and have seen it hundreds of times since though. The last
> > time was at the Smithsonian (or was it the National History Museum?),
> > Iperhaps ten years ago. Here's a web site that's sorta the same thing
> > as the movie, though without the starship. ;-)
> >
> > http://microcosm.web.cern.ch/microcosm/P10/english/P7.h...
>
> Oh, this. There's also a nice series at
> http://www.powersoften.com

....can't get there from here

> The decades where things don't change much are interesting.
> Odd how information clusters.

--
Keith
Anonymous
a b à CPUs
September 24, 2004 1:15:51 AM

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

Keith R. Williams <krw@att.bizzzz> wrote:
> Well I just turned "34" on Sunday. ;-) We're obviously
> talking about a different movie.

hex Congatulations! I'm guessing it must be different.

>> http://www.powersoften.com
> ...can't get there from here

Of course not! The lake is in the way. You have to drive
around, or venture into Canukistan. When they ask about
firearms at the border, the polite response is: "Sure!
What do you need?" They _are_ somewhat impoverished. :) 

More seriously, you could set up an ssh tunnel forwarding
X11 thru the corp firewall. Private surfing, maybe a bit
slow depending on your broadband upload.

-- Robert
September 25, 2004 4:07:16 PM

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

On Thu, 23 Sep 2004 21:15:51 +0000, Robert Redelmeier wrote:

> Keith R. Williams <krw@att.bizzzz> wrote:
>> Well I just turned "34" on Sunday. ;-) We're obviously
>> talking about a different movie.
>
> hex Congatulations! I'm guessing it must be different.
>
>>> http://www.powersoften.com
>> ...can't get there from here
>
> Of course not! The lake is in the way.

Two lakes; one at each end.

> You have to drive
> around, or venture into Canukistan. When they ask about
> firearms at the border, the polite response is: "Sure!
> What do you need?" They _are_ somewhat impoverished. :) 

When I've crossed into CanuCkistan the people at the gates seem to be
seriously lacking a funny bone. The last time (July) I crossed into
Cornwall ON, I thought they were going to send me to border-jail because
my wife sniggered when they asked if I had more than $10K in funny-money
on me.

> More seriously, you could set up an ssh tunnel forwarding X11 thru the
> corp firewall. Private surfing, maybe a bit slow depending on your
> broadband upload.

Naw, it worked yesterday. It seems our firewalls are somewhat overloaded
(we can't afford these hardware thingies you see, since according to RM,
we don't make any money ;-).

--
Keith
Anonymous
a b à CPUs
September 26, 2004 4:25:53 AM

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

On Sat, 25 Sep 2004 12:07:16 -0400, keith <krw@att.bizzzz> wrote:
>> You have to drive
>> around, or venture into Canukistan. When they ask about
>> firearms at the border, the polite response is: "Sure!
>> What do you need?" They _are_ somewhat impoverished. :) 
>
>When I've crossed into CanuCkistan the people at the gates seem to be
>seriously lacking a funny bone. The last time (July) I crossed into
>Cornwall ON,

<shudder> There's your first problem right there, Cornwall ranks
right up there with Geraldton as the worst city in all of Canada! :>

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
September 26, 2004 4:27:50 PM

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

On Sun, 26 Sep 2004 00:25:53 -0400, Tony Hill wrote:

> On Sat, 25 Sep 2004 12:07:16 -0400, keith <krw@att.bizzzz> wrote:
>>> You have to drive
>>> around, or venture into Canukistan. When they ask about
>>> firearms at the border, the polite response is: "Sure!
>>> What do you need?" They _are_ somewhat impoverished. :) 
>>
>>When I've crossed into CanuCkistan the people at the gates seem to be
>>seriously lacking a funny bone. The last time (July) I crossed into
>>Cornwall ON,
>
> <shudder> There's your first problem right there, Cornwall ranks
> right up there with Geraldton as the worst city in all of Canada! :>

Sure beats *any* Quebec crossing! <gack> ...gunna run into water any
further west.
!