Chambers wrote:
> No, but I've heard a *lot* of people say that Linux (of any variety!) is
> significantly more annoying that Windows!

It's also a lot easier to be less annoying when you can blame the most 
annoying problems in Linux on Microsoft anyway. </sarcasm>

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Orchid XP v8 wrote:
> > Now if it really *was* faster, people would notice that. And they'd like 
> > it. Trouble is, they also notice when the reverse happens...

> I haven't seen any reviews of Vista complaining the actual released 
> version was slower.

  Slower than what? XP? Well, there's at least this:

http://www.tomshardware.com/reviews/xp-vs-vista,1531.html

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Slower than what? XP? Well, there's at least this:
> http://www.tomshardware.com/reviews/xp-vs-vista,1531.html

That was pretty good. I'm actually rather surprised that there's a 
noticeable difference in speed on computer-bound tasks like encoding. 
You would think that there isn't much you can do to hurt that, but 
perhaps some of the changes like tighter scheduling is adding overhead 
that isn't useful when you only have one compute-bound task running. 
Even so, 20% seems rather a large overhead for something like that.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Nicolas Alvarez wrote:
> I recall reports of very beta versions of Vista having security bugs in the
> TCP/IP stack that had been fixed in Windows 95.

Heck, these kind of problems were found and fixed in the first TCP 
bake-offs in the early 70's. Yet, somehow, everyone who writes a TCP 
stack doesn't seem to bother to check for these things.  Ping-of-death, 
christmas tree packets, martian packets, all these are stuff people 
figured out would be problems around 1972, and published their results 
as RFCs, yet implementors seem to never learn.

How many years did Sun recommend you turn off pings at the firewall so 
nobody sent you a ping with a source address being the broadcast address?

I guess by the time it's time to write a new TCP stack, it's a new 
generation of programmers working on it.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New wrote:
> Even so, 20% seems rather a large overhead for something like that.

Actually, Vista does power saving by turning down the CPU speed and 
limiting the maximum speed.  Tom's Hardware is generally pretty 
cluefull, and their benchmarks are pretty well documented and all, but I 
wonder if they turned that off.  I'd read someone else say it could take 
a couple of seconds for your programs to get up to speed, but I thought 
that sounded pretty silly. Now I have to wonder if they were right and 
Vista really does keep the CPU slow for longer than I'd expect. Hmmmm...

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New wrote:
> Actually, Vista does power saving by turning down the CPU speed and
> limiting the maximum speed.  Tom's Hardware is generally pretty
> cluefull, and their benchmarks are pretty well documented and all, but I
> wonder if they turned that off.  I'd read someone else say it could take
> a couple of seconds for your programs to get up to speed, but I thought
> that sounded pretty silly. Now I have to wonder if they were right and
> Vista really does keep the CPU slow for longer than I'd expect. Hmmmm...
> 

After months of running Ubuntu, I discovered it was throttling the CPU. I
keep nice 19 processes using 100% CPU 24/7, and I want all the speed I can
get from the CPU.

(they're nice 19 just so they don't make the desktop slower, I still want
them to run as fast as they can)

I had to set some relatively obscure parameter to "performance"
(was "ondemand").

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> After months of running Ubuntu, I discovered it was throttling the CPU. I
> keep nice 19 processes using 100% CPU 24/7, and I want all the speed I can
> get from the CPU.

> (they're nice 19 just so they don't make the desktop slower, I still want
> them to run as fast as they can)

  In my experience even if there is only one single CPU-intensive process
running at nice level 19 it will run slower than if it was running eg. at
nice level 4 (which is the default for nice when you don't specify a number).

  I'm not exactly sure why this is so nor do I have any references to this,
but it's what I have experienced. Maybe a process at nice level 19 really
is at the very bottom of the barrel and *anything* will override it, no
matter how light. For this reason whenever I want to make a process (such
as povray) run with a lower scheduling priority I just use the default nice
level (ie. 4). That seems to give basically all free CPU to the process but
will not hinder other processes which temporarily need it more. Also in this
case the nice 4 process still gets a fair share of the CPU and doesn't get
completely halted.

  Also in my experience nice level 4 is completely enough to keep a heavy
process, well, nice. For example I have run long povray renders with nice
level 4 and at the same time watched videos with mplayer without any
problems.

  I suppose the only cases where you want to use a nice value different
from 4 is when you want two or more heavy processes running at the same
time and you want one of them getting more CPU than the others. The
difference in priorites will affect how the CPU is shared between them.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   In my experience even if there is only one single CPU-intensive process
> running at nice level 19 it will run slower than if it was running eg. at
> nice level 4 (which is the default for nice when you don't specify a
> number).

The "task scheduler" (BOINC) already sets tasks at nice 19, using system
calls. I'm not manually running it with the 'nice' command.

If there is nothing else to use CPU, why would nice 19 be slower than nice
4?

>   I'm not exactly sure why this is so nor do I have any references to
>   this,
> but it's what I have experienced. Maybe a process at nice level 19 really
> is at the very bottom of the barrel and *anything* will override it, no
> matter how light. For this reason whenever I want to make a process (such
> as povray) run with a lower scheduling priority I just use the default
> nice level (ie. 4). That seems to give basically all free CPU to the
> process but will not hinder other processes which temporarily need it
> more. Also in this case the nice 4 process still gets a fair share of the
> CPU and doesn't get completely halted.
> 
>   Also in my experience nice level 4 is completely enough to keep a heavy
> process, well, nice. For example I have run long povray renders with nice
> level 4 and at the same time watched videos with mplayer without any
> problems.
> 
>   I suppose the only cases where you want to use a nice value different
> from 4 is when you want two or more heavy processes running at the same
> time and you want one of them getting more CPU than the others. The
> difference in priorites will affect how the CPU is shared between them.

Interestingly there have been some BOINC users complaining that even at nice
19, if a user process tries to use all the CPU at nice 0, the BOINC app
will still use 5% of CPU.

Post a reply to this message

Nicolas Alvarez wrote
> The "task scheduler" (BOINC) already sets tasks at nice 19, using system
> calls. I'm not manually running it with the 'nice' command.

Since I'm already running a version I compiled from source (and modified
quite a bit), I could change the nice level if I wanted to...


There is also new problems now that there are GPGPU applications. When
running at low priority, the application computed REALLY slow. The GPU
starved because the CPU couldn't feed it with data often enough.

But if the app ran at normal priority, it used like 2% of CPU, so it didn't
make the machine slow... So now GPU apps are run at normal priority. (there
is still a problem on Windows, where it's using over 20% CPU).

Post a reply to this message

Warp wrote:
>   Also in my experience nice level 4 is completely enough to keep a heavy
> process, well, nice. 

I think that's probably true of CPU-bound processes. I've had trouble 
getting I/O bound processes to play well with others (under both XP and 
Linux) because the nice value doesn't affect them. Plus, the "ionice" 
bit seems pretty primitve, and the ionice processes don't run unless you 
completely stop using the disk for several seconds, it seems.

Unfortunately, most of my actual paying work is I/O bound, not CPU bound.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message