Mike Silbersack wrote:
> I was looking at the timer implementation a few weeks ago and pondering if
> it could be improved as well. I think it's quite clever if you're dealing
> with a quantity of timers < 1000 or so, but it looks like it could be more
> optimal when used with the quantity of tim
On Fri, 1 Feb 2002, Terry Lambert wrote:
> I guess you are talking the LRP stuff.
>
> I was just talking about the processing at NETISR as a
> result of a higher HZ causing a higher softintr run
> frequency.
Interesting; I hadn't considered that scheduling could have an effect on
performance, b
On Fri, 1 Feb 2002, Luigi Rizzo wrote:
> HZ also has an impact on select() behaviour when timeouts are
> used (and device drivers using timeouts as well).
> A lot of software uses select() with a very short timeout which
> is usually rounded up to the next tick. If the author of the software
> i
"DOROVSKOY,IGOR (A-Portsmouth,ex1)" wrote:
> I've made HZ=10 and ran few very simple tests (icmp, udp)
> thrue gbe interface (3C985B-SX and GA620) against same system
> with HZ=100. To transmit - no big difference. For recieve side
> "overclocked" system bet regular in times. In my case wasn't
nt: Friday, February 01, 2002 4:36 PM
To: Storms of Perfection
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Clock Granularity (kernel option HZ)
I've been running for quite some time a 5.0-CURRENT box with HZ=1000
set to it's kernel configuration. Apart from a faster blinking
I've been running for quite some time a 5.0-CURRENT box with HZ=1000
set to it's kernel configuration. Apart from a faster blinking rate
of the syscons cursor, I haven't seen much difference. This is my own
personal workstation though, and it's almost never loaded too much :-/
- Giorgos
On 200
Luigi Rizzo wrote:
> but exactly because of this reason, the overhead of netisr should
> be less and less relevant as the processing increases.
Not really. You are barriered up and down, and in any
request/response, you won't be able to process both in
the same NETISR, it will take (at least) 2
Alfred Perlstein wrote:
> Forwarding packets is a lot less complicated than doing tcp
> recieve and send. I haven't seen Terry's stuff in action,
> however it makes sense that tcp would see more of an improvement
> than simple IP forwarding.
I guess you are talking the LRP stuff.
I was just tal
Luigi Rizzo wrote:
> On Thu, Jan 31, 2002 at 04:59:31PM -0800, Terry Lambert wrote:
> > You will get a factor of 6 (approximately) improvement in
> > throughput vs. overhead if you process packets to completion
> > at interrupt, and process writes to completion at write time
> > from the process.
On Fri, Feb 01, 2002 at 12:28:35AM -0800, Alfred Perlstein wrote:
> > > throughput vs. overhead if you process packets to completion
> > > at interrupt, and process writes to completion at write time
> > > from the process.
> >
> > this does not match my numbers. e.g. using "fastforwarding"
> > (
* Luigi Rizzo <[EMAIL PROTECTED]> [020201 00:25] wrote:
> On Thu, Jan 31, 2002 at 04:59:31PM -0800, Terry Lambert wrote:
> >
> > You will get a factor of 6 (approximately) improvement in
> > throughput vs. overhead if you process packets to completion
> > at interrupt, and process writes to compl
On Thu, Jan 31, 2002 at 04:59:31PM -0800, Terry Lambert wrote:
>
> You will get a factor of 6 (approximately) improvement in
> throughput vs. overhead if you process packets to completion
> at interrupt, and process writes to completion at write time
> from the process.
this does not match my nu
On Thu, Jan 31, 2002 at 05:33:28PM +, Mike Silbersack wrote:
>
> On Thu, 31 Jan 2002, Storms of Perfection wrote:
>
> > I'm going to benchmark different network senarious with different options
> > to see what I can get, and what works best. If someone wants to help me
> > out, I could mayb
Eugene Panchenko wrote:
> I've seen various postings on the Net where people reported
> network-related and overall performance improvements caused
> by settig HZ kernel option to 1000 (for example), that is,
> reducing a tick size to 1ms for their FreeBSD and Linux
> systems.
This is a NETISR pr
Mike Silbersack wrote:
> The TCP stack, on the other hand, is perfectly happy with 10ms resolution.
> Retransmission timeouts are only actually used when loss occurs on the
> network, and 10ms is more than accurate enough for retransmission. (I
> believe that retransmit timeouts are rounded up to
Storms of Perfection wrote:
> Ok. Since I have a limited hardware/software set at my finger tips. I can
> generate an attack on my machine (such as a synflood or something) to see
> what type of reponses I can get by setting it up and down. I think this may
> apply to this feature, to help the ma
On Thu, 31 Jan 2002, Michael Meltzer wrote:
> Not knowing but wondering:
> With Gigabit Ethernet and NFS in the mix, anything that gets latency out is
> a very good thing :-) and would improve performance.
>
> MJM
Even in those cases, the increased resolution will not help you. 10ms is
more th
Message -
From: "Storms of Perfection" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Thursday, January 31, 2002 7:10 PM
Subject: Re: Clock Granularity (ke
;[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Thursday, January 31, 2002 12:33 PM
> Subject: Re: Clock Granularity (kernel option HZ)
>
>
>>
>> On Thu, 31 Jan 2002, Storms of Perfection wrote:
>>
EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, January 31, 2002 12:33 PM
Subject: Re: Clock Granularity (kernel option HZ)
>
> On Thu, 31 Jan 2002, Storms of Perfection wrote:
>
> > I'm going to benchmark di
On Thu, 31 Jan 2002, Storms of Perfection wrote:
> I'm going to benchmark different network senarious with different options
> to see what I can get, and what works best. If someone wants to help me
> out, I could maybe write up a article about it?
I don't think you'll end up seeing the perfor
I vote for HZ=10. What would be our test plan?
Igor.
>I'm going to benchmark different network senarious with different options
>to see what I can get, and what works best. If someone wants to help me
>out, I could maybe write up a article about it?
>> I've used a large collection of PCs r
On Thu, 31 Jan 2002 17:36:10 -0500 (EST)
"Storms of Perfection" <[EMAIL PROTECTED]> wrote:
> I'm going to benchmark different network senarious with
> different options
> to see what I can get, and what works best. If someone
> wants to help me
> out, I could maybe write up a article about it?
I'm going to benchmark different network senarious with different options
to see what I can get, and what works best. If someone wants to help me
out, I could maybe write up a article about it?
> I've used a large collection of PCs running somewhat real-time network
> analysis with a HZ set at 5
I've used a large collection of PCs running somewhat real-time network
analysis with a HZ set at 5000Hz with absolutely no ill effects (this
was with P-III-450's)
using HZ=1 was outside of the possibilities of the machines.
one big gain is with timing, which will be better (I myself used NTP
I am intrested in this as well.
> Hello!
>
> I've seen various postings on the Net where people reported
> network-related and overall performance improvements caused
> by settig HZ kernel option to 1000 (for example), that is,
> reducing a tick size to 1ms for their FreeBSD and Linux
> systems.
Hello!
I've seen various postings on the Net where people reported
network-related and overall performance improvements caused
by settig HZ kernel option to 1000 (for example), that is,
reducing a tick size to 1ms for their FreeBSD and Linux
systems. However, several problems seem to arise, such
27 matches
Mail list logo
