Mailing List Archive

That *might* just about do it if you use a PVR-250. 500MHz is close to the
minimum for playback. I believe there are folks out there with PVR-250's in
machines near that speed; perhaps they could shed some more light.

-JAC

> -----Original Message-----
> From: mythtv-users-bounces@snowman.net
> [mailto:mythtv-users-bounces@snowman.net]On Behalf Of Forrest Aldrich
> Sent: Friday, May 30, 2003 2:40 PM
> To: Discussion about mythtv
> Subject: [mythtv-users] Basic requirements (hardware)
>
>
> I have an older Compaq 500mhz system, which I could cannibalize for a
> project like this -- but from the MythTV pages, I'm presuming
> this won't be
> powerful enough.
>
> Anyone have experience with machines of this nature.

With 1 tuner card, set at resolutions < 480x480
(especially something like 640-480x240) it should work using
rtjpeg. Definately watchable, but you will notice some quality loss.

I have a dual P2-450 with 3 cards, I capture at 640x240 @200 rtjpeg
without too many problems.


Brian

On Fri, 30 May 2003, Forrest Aldrich wrote:

> I have an older Compaq 500mhz system, which I could cannibalize for a
> project like this -- but from the MythTV pages, I'm presuming this won't be
> powerful enough.
>
> Anyone have experience with machines of this nature.
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@snowman.net
> http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users
>
>

At 02:57 PM 5/30/2003 -0400, Joseph A. Caputo wrote:
>That *might* just about do it if you use a PVR-250. 500MHz is close to the
>minimum for playback. I believe there are folks out there with PVR-250's in
>machines near that speed; perhaps they could shed some more light.


I think you are right, Joe ... at least it matches my experience with Myth
... but do you (or does anyone) know *why* this is true? I ask because I've
done playback of DivX'd DVDs, using xine or mplayer, on much lighterweight
hardware ... a K6-300, so old that the mobo had slots for 72-pin RAM, that
I used to have comes to mind ... with only about a 50-60% CPU load. What
does Myth *playback* do that is so demanding of CPU. compared to these
other playback apps?

If you want to build a "test" system before dropping money into a new box,
I'd go for it. I'm running an athlon 650/256MB RAM with two WinTV 401 tuner
cards. I set the quality to 320x480 and approx. 1800 bitrate and I can
record two shows at once or play one and record one, live TV while not
recording anything even works pretty well. I do want a faster system so it
is more capable, but until the funds are there this is doing nicely.

Sherm <><
--------------------------------
Kelly Reed Schuerman
kschuerman@thekeyboardcowboy.com
http://www.thekeyboardcowboy.com

> -----Original Message-----
> From: mythtv-users-bounces@snowman.net
> [mailto:mythtv-users-bounces@snowman.net] On Behalf Of Forrest Aldrich
> Sent: Friday, May 30, 2003 1:40 PM
> To: Discussion about mythtv
> Subject: [mythtv-users] Basic requirements (hardware)
>
>
> I have an older Compaq 500mhz system, which I could cannibalize for a
> project like this -- but from the MythTV pages, I'm presuming
> this won't be
> powerful enough.
>
> Anyone have experience with machines of this nature.
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@snowman.net
> http://lists.snowman.net/cgi-> bin/mailman/listinfo/mythtv-users
>

> -----Original Message-----
> From: mythtv-users-bounces@snowman.net
> [mailto:mythtv-users-bounces@snowman.net]On Behalf Of Ray Olszewski
> Sent: Friday, May 30, 2003 3:17 PM
> To: Discussion about mythtv
> Subject: RE: [mythtv-users] Basic requirements (hardware)
>
> I think you are right, Joe ... at least it matches my experience
> with Myth
> ... but do you (or does anyone) know *why* this is true? I ask
> because I've
> done playback of DivX'd DVDs, using xine or mplayer, on much
> lighterweight
> hardware ... a K6-300, so old that the mobo had slots for 72-pin
> RAM, that
> I used to have comes to mind ... with only about a 50-60% CPU load. What
> does Myth *playback* do that is so demanding of CPU. compared to these
> other playback apps?


Hmmm... are you talking full-screen playback, or windowed? The older,
slower systems (~300-400 MHz) used to come with hardware MPEG decoder boards
that the DVD drive plugged into. Did you have one of those on your system?
Also, I guess even a slower system would benefit from a modern video card
that supports XV, so it doesn't have to to all the video & scaling in
software. I dunno... I'd just always heard that 450-500 MHz was kind of the
lower limit for full-screen MPEG decoding/playback, unless you have a
decoder board.

-JAC

At 03:34 PM 5/30/2003 -0400, Joseph A. Caputo wrote:
>Hmmm... are you talking full-screen playback, or windowed? The older,
>slower systems (~300-400 MHz) used to come with hardware MPEG decoder boards
>that the DVD drive plugged into. Did you have one of those on your system?

No. This was a setup I put together recently, using some AGP card that
supported xVideo (an ATI card, I think) on standard VGA output (not
TV-out). I ran xine either fullscreen, at 100%, or at 200% of capture size,
on an 640x480 X display. (TV caps were 320x240 DivX; DVDs varied but were a
lot finer, usually 7??x480 DivX).

I never tried to play back a DVD itself (no DVD drive in that system), just
the DivX re-encodings

>Also, I guess even a slower system would benefit from a modern video card
>that supports XV, so it doesn't have to to all the video & scaling in
>software. I dunno... I'd just always heard that 450-500 MHz was kind of the
>lower limit for full-screen MPEG decoding/playback, unless you have a
>decoder board.

As I said, this appears to be true for Myth playback, which has much higher
demands on systems than (say) xine. On my 1.7 GHz Cel, for example, Myth
uses about 30% of CPU during playback, right in the 450-500 range. But xine
uses <5% ... though I've only tried 320x240 TV caps, roughly 500 MB/hr,
with xine on this system not Divx re-encodes of DVDs.

On Friday 30 May 2003 04:01 pm, Ray Olszewski wrote:
> As I said, this appears to be true for Myth playback, which has much higher
> demands on systems than (say) xine. On my 1.7 GHz Cel, for example, Myth
> uses about 30% of CPU during playback, right in the 450-500 range. But xine
> uses <5% ... though I've only tried 320x240 TV caps, roughly 500 MB/hr,
> with xine on this system not Divx re-encodes of DVDs.

Just as another data point, on my main machine (xp 1800+), playback of
full-sized video in mythtv takes around 3-5% cpu for mpeg4 encodes, and just
slightly higher for the mpeg2 encodes from my pvr-250. Both of those are
with deinterlacing turned on. Playback of the mpeg2 encodes with other
programs (xine/mplayer), is similar.

Isaac

The reason 500Mhz is close to minimum if you have a PVR250 is that, no
matter what your capture resolution, you are capturing at a bitrate of
16Mb/sec. That's 2MB/sec which is a hell of a lot of data to be grabbing
and decoding, a lot more than your average DIVX.

Once MythTV supports the changing of the bitrate for the PVR250, a
500Mhz machine should be fine for playback of captured movies. I have a
450Mhz machine and it's just fractionally too slow for playback. You
might scrape it with a 500Mhz machine, but once we can lower bitrate,
there will be no problem.

Is there any word about when MythTV will support programmable bitrates
for the PVR250?

Andy

-----Original Message-----
From: mythtv-users-bounces@snowman.net
[mailto:mythtv-users-bounces@snowman.net] On Behalf Of Joseph A. Caputo
Sent: 30 May 2003 7:57 PM
To: Discussion about mythtv
Subject: RE: [mythtv-users] Basic requirements (hardware)


That *might* just about do it if you use a PVR-250. 500MHz is close to
the minimum for playback. I believe there are folks out there with
PVR-250's in machines near that speed; perhaps they could shed some more
light.

-JAC

> -----Original Message-----
> From: mythtv-users-bounces@snowman.net
> [mailto:mythtv-users-bounces@snowman.net]On Behalf Of Forrest Aldrich
> Sent: Friday, May 30, 2003 2:40 PM
> To: Discussion about mythtv
> Subject: [mythtv-users] Basic requirements (hardware)
>
>
> I have an older Compaq 500mhz system, which I could cannibalize for a
> project like this -- but from the MythTV pages, I'm presuming this
> won't be powerful enough.
>
> Anyone have experience with machines of this nature.

_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

I had a spare P3-550Mhz server sitting around, so I decided to take
advantage of the $100 Hauppauge PVR-250 deal and just make a backend MythTV
server (for now) using MythWEB for scheduling. I use other computers on my
network to watch the recordings (servered by Samba/NFS) and it works very
nice as a first step.

Steve


On Fri, May 30, 2003 at 02:40:21PM -0400, Forrest Aldrich wrote:
> I have an older Compaq 500mhz system, which I could cannibalize for a
> project like this -- but from the MythTV pages, I'm presuming this won't be
> powerful enough.
>
> Anyone have experience with machines of this nature.

Once the ivtv driver supports it, I would imagine...

-JAC


On Friday 30 May 2003 05:05 pm, Andrew Ingram wrote:
>
> Is there any word about when MythTV will support programmable bitrates
> for the PVR250?
>
> Andy

On Friday 30 May 2003 08:42 pm, Joseph A. Caputo wrote:
> On Friday 30 May 2003 05:05 pm, Andrew Ingram wrote:
> > Is there any word about when MythTV will support programmable bitrates
> > for the PVR250?
>
> Once the ivtv driver supports it, I would imagine...

The driver does, actually, it's just that the interface for changing it isn't
the final one, so I don't really see any point in supporting it or the other
encoding options just yet. The various options do persist until a reboot, so
unless you want different recording options for live-tv and scheduled
recordings (and I can't think of a reason why you would), the test_ioctl
program's plenty enough to take care of setting the bitrate for now.

Isaac

At 10:25 PM 5/30/2003 -0400, you wrote:
>On Friday 30 May 2003 08:42 pm, Joseph A. Caputo wrote:
> > On Friday 30 May 2003 05:05 pm, Andrew Ingram wrote:
> > > Is there any word about when MythTV will support programmable bitrates
> > > for the PVR250?
> >
> > Once the ivtv driver supports it, I would imagine...
>
>The driver does, actually, it's just that the interface for changing it isn't
>the final one, so I don't really see any point in supporting it or the other
>encoding options just yet. The various options do persist until a reboot, so
>unless you want different recording options for live-tv and scheduled
>recordings (and I can't think of a reason why you would), the test_ioctl
>program's plenty enough to take care of setting the bitrate for now.

On this note, I have done some playing around and added this line to my
/etc/rc.local on my RH9 system (I have some other test_ioctl functions
above it). This setting results in almost exactly 2GB an hour files, and I
have noticed no quality difference between it and the default setting.

# Turn down the sample rate for smaller files - about 2GB/hour
~jac/ivtv/ivtv/utils/test_ioctl -c bitrate=4000000,bitrate_peak=10000000

-Jeff

At 04:16 PM 5/30/2003 -0400, Isaac Richards wrote:
>On Friday 30 May 2003 04:01 pm, Ray Olszewski wrote:
> > As I said, this appears to be true for Myth playback, which has much higher
> > demands on systems than (say) xine. On my 1.7 GHz Cel, for example, Myth
> > uses about 30% of CPU during playback, right in the 450-500 range. But xine
> > uses <5% ... though I've only tried 320x240 TV caps, roughly 500 MB/hr,
> > with xine on this system not Divx re-encodes of DVDs.
>
>Just as another data point, on my main machine (xp 1800+), playback of
>full-sized video in mythtv takes around 3-5% cpu for mpeg4 encodes, and just
>slightly higher for the mpeg2 encodes from my pvr-250. Both of those are
>with deinterlacing turned on. Playback of the mpeg2 encodes with other
>programs (xine/mplayer), is similar.

Interesting. So do you think my considerably higher numbers (even allowing
for the CPU difference, I think) indicate some sort of configuration error?
If so ... any thoughts on the candidate? Or are Celerons really that mush
worse than Athlons? Or is Myth optimized for Athlons in some subtle way?

Jeff C wrote:

> # Turn down the sample rate for smaller files - about 2GB/hour
> ~jac/ivtv/ivtv/utils/test_ioctl -c bitrate=4000000,bitrate_peak=10000000

jeff, in another thread you talk about jerky video, particularly during
transition points. i have noticed that if i set my bitrate anything
below about 4.5Mb/s, then i start getting jerky audio. if i set it to
2.5Mb/s, then it is almost always skipping.

i haven't had a chance to play around with this and get a proper report
together, but if you could test it at 2.5Mbps and lemme know if the
problem get worse, i'd appreciate it. i'm on an athlon 1GHz (similar to
you) but i don't think the processor speed is the issue, i rarely break
10% watching mpeg-2 streams. for the time being, i just went back to 8Mb/s.

cheers,

CraigL->Thx();

At 11:09 AM 5/31/2003 -0400, you wrote:
>Jeff C wrote:
>
>># Turn down the sample rate for smaller files - about 2GB/hour
>>~jac/ivtv/ivtv/utils/test_ioctl -c bitrate=4000000,bitrate_peak=10000000
>
>jeff, in another thread you talk about jerky video, particularly during
>transition points. i have noticed that if i set my bitrate anything below
>about 4.5Mb/s, then i start getting jerky audio. if i set it to 2.5Mb/s,
>then it is almost always skipping.
>
>i haven't had a chance to play around with this and get a proper report
>together, but if you could test it at 2.5Mbps and lemme know if the
>problem get worse, i'd appreciate it. i'm on an athlon 1GHz (similar to
>you) but i don't think the processor speed is the issue, i rarely break
>10% watching mpeg-2 streams. for the time being, i just went back to 8Mb/s.



Excellent feedback Craig, thank you. I am going out of town for a bit but
I will make the change and ask my wife to keep an eye on it. The audio
problem is fairly rare, maybe 1-2 times in a half hour and lasts about 30
seconds.

-Jeff

At 11:09 AM 5/31/2003 -0400, you wrote:
>Jeff C wrote:
>
>># Turn down the sample rate for smaller files - about 2GB/hour
>>~jac/ivtv/ivtv/utils/test_ioctl -c bitrate=4000000,bitrate_peak=10000000
>
>jeff, in another thread you talk about jerky video, particularly during
>transition points. i have noticed that if i set my bitrate anything below
>about 4.5Mb/s, then i start getting jerky audio. if i set it to 2.5Mb/s,
>then it is almost always skipping.
>
>i haven't had a chance to play around with this and get a proper report
>together, but if you could test it at 2.5Mbps and lemme know if the
>problem get worse, i'd appreciate it. i'm on an athlon 1GHz (similar to
>you) but i don't think the processor speed is the issue, i rarely break
>10% watching mpeg-2 streams. for the time being, i just went back to 8Mb/s.

Craig,

What speed disk are you using? I'm on a 5400RPM disk with only a 2MB
cache, and I am wondering if that might also be contributing? I intend to
go to a 120 or 160 GB drive at 7200RPM with an 8MB cache in a month or so,
but until then I'm curious to know what you are using.

-Jeff

Jeff C wrote:

> At 11:09 AM 5/31/2003 -0400, you wrote:
>
>> Jeff C wrote:
>>
>>> # Turn down the sample rate for smaller files - about 2GB/hour
>>> ~jac/ivtv/ivtv/utils/test_ioctl -c bitrate=4000000,bitrate_peak=10000000
>>
>> jeff, in another thread you talk about jerky video, particularly
>> during transition points. i have noticed that if i set my bitrate
>> anything below about 4.5Mb/s, then i start getting jerky audio. if i
>> set it to 2.5Mb/s, then it is almost always skipping.
>
> What speed disk are you using? I'm on a 5400RPM disk with only a 2MB
> cache, and I am wondering if that might also be contributing? I
> intend to go to a 120 or 160 GB drive at 7200RPM with an 8MB cache in
> a month or so, but until then I'm curious to know what you are using.

i think its a 5400, but i forget what i've got where now.

the thing i don't understand though, is LOWERing the bitrate shouldn't
expose bad disk performance problems. it /might/ expose insufficient
cpu, but then i would think that my proc usage should go up. having it
not go up, maybe indicates bus performance problems, but i'm not sure.
i think the most likely candidate is timing problems, but thats what i
need to investigate.

one thing i thought though, if you're going away, you might not want to
screw around with it. if lowering it further does cause problems on
your system, then it will be un-usable for you wife. i know mine
doesn't really care for all the experimenting i'm doing with our main tv
source... especially if it interferes with things like ER...;-)

cheers,

CraigL->Thx();

At 11:37 AM 5/31/2003 -0400, you wrote:

>i think its a 5400, but i forget what i've got where now.

Hmm, when you get a chance can you check this, I'm just curious - one of my
random thoughts on what might be going on. In the past I have seen IO
buffer related errors but haven't seen them lately.

>the thing i don't understand though, is LOWERing the bitrate shouldn't
>expose bad disk performance problems. it /might/ expose insufficient cpu,
>but then i would think that my proc usage should go up. having it not go
>up, maybe indicates bus performance problems, but i'm not sure. i think
>the most likely candidate is timing problems, but thats what i need to
>investigate.

Agreed on disk performance, but who knows... I am also using my system a
lot more so more of the disk is being used - so maybe the seeking around is
catching up with me every now and then - not a lot of apps do such high
bandwidth continuous reads where you would notice a small thing like some
frame/audio synching. I think having a bigger disk cache would help...

>one thing i thought though, if you're going away, you might not want to
>screw around with it. if lowering it further does cause problems on your
>system, then it will be un-usable for you wife. i know mine doesn't
>really care for all the experimenting i'm doing with our main tv source...
>especially if it interferes with things like ER...;-)

That's the challenge with running a project at the stage Myth it - on the
one hand it looks amazing and completely ready for prime time (IE my wife
fell in love with it and sees it as part of our AV system now) and on the
other, I still like to do regular updates and tweaking to get little things
sorted out. But messing with ER is definitely a no no. I already
accidentally erased the season finale and had to find it on Kazaa ;)

-Jeff

On Sat, May 31, 2003 at 01:06:22PM -0300, Jeff C wrote:
> sorted out. But messing with ER is definitely a no no. I already
> accidentally erased the season finale and had to find it on Kazaa ;)

that's a reason to keep kazaa alive... if someone "experiments" with
mythv, that would be the end of the project if it weren't for kazaa...

Frank

Craig Longman [craigl@begeek.com] wrote:
> Jeff C wrote:
>
> > At 11:09 AM 5/31/2003 -0400, you wrote:
> >
> >> Jeff C wrote:
> >>
> >>> # Turn down the sample rate for smaller files - about 2GB/hour
> >>> ~jac/ivtv/ivtv/utils/test_ioctl -c bitrate=4000000,bitrate_peak=10000000
> >>
> >> jeff, in another thread you talk about jerky video, particularly
> >> during transition points. i have noticed that if i set my bitrate
> >> anything below about 4.5Mb/s, then i start getting jerky audio. if i
> >> set it to 2.5Mb/s, then it is almost always skipping.
> >
> > What speed disk are you using? I'm on a 5400RPM disk with only a 2MB
> > cache, and I am wondering if that might also be contributing? I
> > intend to go to a 120 or 160 GB drive at 7200RPM with an 8MB cache in
> > a month or so, but until then I'm curious to know what you are using.
>
> i think its a 5400, but i forget what i've got where now.
>
> the thing i don't understand though, is LOWERing the bitrate shouldn't
> expose bad disk performance problems. it /might/ expose insufficient
> cpu, but then i would think that my proc usage should go up. having it
> not go up, maybe indicates bus performance problems, but i'm not sure.
> i think the most likely candidate is timing problems, but thats what i
> need to investigate.
>
> one thing i thought though, if you're going away, you might not want to
> screw around with it. if lowering it further does cause problems on
> your system, then it will be un-usable for you wife. i know mine
> doesn't really care for all the experimenting i'm doing with our main tv
> source... especially if it interferes with things like ER...;-)

I doubt that it has to deal with lowering the bitrate, it's probably
something else that is showing up as a side effect of the lowering of
the bitrate. I set my bitrate to bitrate=2500000,bitrate_peak=5000000
and haven't noticed any problems. And I'm even running on slower
hardware than you guys (700MHz athlon, 4500 RPM disk drive). So if it
is a bitrate problem, I'm not experiencing it.

I was getting some skipping at first, then I realized that spamassassin
was causing it (non-dedicated box). I changed it to run spamd and force
a nice level of 15 for spamd and the jitters went away.

--Patrick

At 01:06 PM 5/31/03 -0300, Jeff C wrote:
>>the thing i don't understand though, is LOWERing the bitrate shouldn't
>>expose bad disk performance problems. it /might/ expose insufficient
>>cpu, but then i would think that my proc usage should go up. having it
>>not go up, maybe indicates bus performance problems, but i'm not sure. i
>>think the most likely candidate is timing problems, but thats what i need
>>to investigate.
>
>Agreed on disk performance, but who knows... I am also using my system a
>lot more so more of the disk is being used - so maybe the seeking around
>is catching up with me every now and then - not a lot of apps do such high
>bandwidth continuous reads where you would notice a small thing like some
>frame/audio synching. I think having a bigger disk cache would help...


Is it possible that the lower bit rate is skipping frames on the encode
side? Not enough bits going through to encode everything?

On Saturday 31 May 2003 10:19 am, Ray Olszewski wrote:
> >Just as another data point, on my main machine (xp 1800+), playback of
> >full-sized video in mythtv takes around 3-5% cpu for mpeg4 encodes, and
> > just slightly higher for the mpeg2 encodes from my pvr-250. Both of
> > those are with deinterlacing turned on. Playback of the mpeg2 encodes
> > with other programs (xine/mplayer), is similar.
>
> Interesting. So do you think my considerably higher numbers (even allowing
> for the CPU difference, I think) indicate some sort of configuration error?
> If so ... any thoughts on the candidate? Or are Celerons really that mush
> worse than Athlons? Or is Myth optimized for Athlons in some subtle way?

I honestly have no idea, unless you happen to be running a debug build of
mythtv. All decoding is happening in libavcodec, and everyone uses that same
lib, essentially =)

Isaac

Patrick Wagstrom wrote:

>Craig Longman [craigl@begeek.com] wrote:
>
>
>>the thing i don't understand though, is LOWERing the bitrate shouldn't
>>expose bad disk performance problems. it /might/ expose insufficient
>>cpu, but then i would think that my proc usage should go up. having it
>>not go up, maybe indicates bus performance problems, but i'm not sure.
>> i think the most likely candidate is timing problems, but thats what i
>>need to investigate.
>>
>>one thing i thought though, if you're going away, you might not want to
>>screw around with it. if lowering it further does cause problems on
>>your system, then it will be un-usable for you wife. i know mine
>>doesn't really care for all the experimenting i'm doing with our main tv
>>source... especially if it interferes with things like ER...;-)
>>
>>
>I doubt that it has to deal with lowering the bitrate, it's probably
>something else that is showing up as a side effect of the lowering of
>the bitrate. I set my bitrate to bitrate=2500000,bitrate_peak=5000000
>and haven't noticed any problems. And I'm even running on slower
>hardware than you guys (700MHz athlon, 4500 RPM disk drive). So if it
>is a bitrate problem, I'm not experiencing it.
>
>I was getting some skipping at first, then I realized that spamassassin
>was causing it (non-dedicated box). I changed it to run spamd and force
>a nice level of 15 for spamd and the jitters went away.
>
yeah, it sounds weird, which is why i hadn't planned on mentioning it
until i looked into it more. but it is definitely just lowering the
bitrate for me, for both livetv and recorded shows. i can set it to
8Mbs, watch no problem, exit livetv, change to 2.5Mbs, and then livetv
skips, exit and switch back to 8Mbs, and it works fine. after switching
back and forth 3 full times, i was reasonably convinced that it was the
bitrate. i even tried going to an older version of the ivtv driver that
i prefer to the current, and it did the same thing. and it is dependant
to the bitrate, at 2.5Mbs, it happens after a little while and pretty
much stays. at 4Mbs, its only every 5-10 minutes, and less noticeable.
at 5Mbs i only noticed it once during a 30 minute show.

anyway, i'm going to try and figure it out once i get transcoding done.
for the time being, 8Mbs works for me.

cheers,

CraigL->Thx();

Ray Olszewski wrote:

> Interesting. So do you think my considerably higher numbers (even
> allowing for the CPU difference, I think) indicate some sort of
> configuration error? If so ... any thoughts on the candidate? Or are
> Celerons really that mush worse than Athlons? Or is Myth optimized for
> Athlons in some subtle way?

I don't think Myth is optimized for Athlons, only the 1.7Ghz Celeron is
a (relatively) crappy CPU for it's price and time - it's lack of cache
is killing it, a P3-based 1.3Ghz Celeron can mostly keep up with it, as
does a Duron 1.3Ghz.

The 1.7Ghz Celeron is not very efficient, that's all... Nearly as bad as
when the L2-cache-less celerons 266 and 300 Mhz got out - and those were
bad!


Pete