Intel Shelton

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.
42 answers Last reply
More about intel shelton
  1. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    It isn't a 64 bit processor though.

    RusH wrote:

    > 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.
  2. 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.
  3. 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.
  4. 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
  5. 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.

    Just as we were talking a conflicting report comes out about Shelton, from
    Xbitlabs:

    http://www.xbitlabs.com/news/cpu/display/20040902154930.html

    They say it's based on Pentium 4. But looking at the original Hkepc article,
    the CPUID clearly shows a Pentium M.

    Yousuf Khan
  6. 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?
  7. 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!
  8. 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
  9. 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
  10. 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!
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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=2149&p=7

    >
    >
    > -- Robert
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
  26. 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
  27. 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
  28. 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
  29. 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
  30. 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
  31. 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
  32. 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
  33. 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
  34. 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
  35. 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
  36. 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.html

    <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
  37. 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.html

    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
  38. 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.html
    >
    > 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
  39. 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
  40. 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
  41. 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
  42. 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.
Ask a new question

Read More

CPUs Hardware Intel