In message <[EMAIL PROTECTED]>, Bruce Evans writes:
>On Fri, 14 Oct 2005, Poul-Henning Kamp wrote:
>> Even to this day new CPU chips come out where TSC has flaws that
>> prevent it from being used as timecounter, and we do not have (NDA)
>> access to the data that would allow us to build a list of
Hi,
Although I don't know the detail of fwe technology, I understand the
technology is a proprietary one. It is better to provide a compatibility
with RFC standard firewire over IP, if some volunteer are there.
On 2005/10/15, at 9:58, Cai, Quanqing wrote:
Hi guys,
When I was fixing bug kern/8
Bruce Evans writes:
> On Fri, 14 Oct 2005, Andrew Gallatin wrote:
>
> > Bear in mind that I have no clue about timekeeping. I got into this
> > just because I noticed using a TSC timecounter reduces context switch
> > latency by 40% or more on all the SMP platforms I have access to:
> >
>
Hi guys,
When I was fixing bug kern/82727:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/82727, I found we use
fwe(Ethernet over FireWire) in GENERIC kernel, not fwip(IP over FireWire).
But we all know that IP over FireWire is more widely used on other OSes, and
now this bug is fixed, do we need
Yes, I tried it just now and got the problem at same place too. But My
system is 7.0-CURRENT.
On 10/14/05, Aluminium Oxide <[EMAIL PROTECTED]> wrote:
>
> Has anyone else seen this?
>
> I received an error on a kernel build during linking, for ubpf.o
>
>
> Just prior to this I had run
> o a cvsup w
Has anyone else seen this?
I received an error on a kernel build during linking, for ubpf.o
Just prior to this I had run
o a cvsup with
RELENG_5_4
and
o run make buildworld with
CFLAGS+=-O2 -pipe -fforce-mem -fforce-addr -funroll-loops
-fcse-follow-jumps
CXXF
On Fri, 14 Oct 2005, Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Andrew Gallatin
writes:
Poul-Henning Kamp writes:
The solution is not faster but less reliable timekeeping, the
solution is to move the scheduler(s) away from using time as an
approximation of cpu cycles.
So you m
On Fri, 14 Oct 2005, Andrew Gallatin wrote:
Bear in mind that I have no clue about timekeeping. I got into this
just because I noticed using a TSC timecounter reduces context switch
latency by 40% or more on all the SMP platforms I have access to:
1.0GHz dual PIII : 50% reduction vs i8254
3.06
On Fri, 14 Oct 2005, Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Andrew Gallatin
writes:
What if somebody were to port the linux TSC syncing code, and use it
to decide whether or not set kern.timecounter.smp_tsc=1? Would you
object to that?
Yes, I would object to that.
Even to
On Fri, 14 Oct 2005, Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Bruce Evans writes:
The timestamps in mi_switch() are taken on the same CPU and only their
differences are used, so they don't even need to be synced. It they
use the TSC, then the TSCs just need to have the same alm
On Fri, 14 Oct 2005, Michael VInce wrote:
I been doing some network benchmarking using netperf and just simple
'fetch' on a new network setup to make sure I am getting the most out of
the router and servers, I thought I would post some results in case some
one can help me with my problems or
In message <[EMAIL PROTECTED]>, Andrew Gallatin
writes:
>
>Poul-Henning Kamp writes:
> > The solution is not faster but less reliable timekeeping, the
> > solution is to move the scheduler(s) away from using time as an
> > approximation of cpu cycles.
>
>So you mean rather than use binuptime() in
I have a few IP# I want to proxy transparently. There is a machine
sitting after the router that I want to use as a proxy. How would I go
about routing out going packets through that proxy from the router? Any
one have any opinions on this or any thing?
_
Poul-Henning Kamp writes:
> The solution is not faster but less reliable timekeeping, the
> solution is to move the scheduler(s) away from using time as an
> approximation of cpu cycles.
So you mean rather than use binuptime() in mi_switch(), use some
per-cpu cycle counter (like rdtsc)?
Heck,
Here are some first pass patches to make the bge driver not break IPMI.
This was tested on a Dell PE850:
bge0: mem
0xfe6f-0xfe6f irq 16 at device 0.0 on pci4
miibus1: on bge0
brgphy0: on miibus1
brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX,
1000baseTX-FD
Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Andrew
> Gallatin
> writes:
>
>> > >What if somebody were to port the linux TSC syncing code, and use it
>> > >to decide whether or not set kern.timecounter.smp_tsc=1? Would you
>> > >object to that?
>> >
>> > Yes, I would object to th
In message <[EMAIL PROTECTED]>, Andrew Gallatin
writes:
> > >What if somebody were to port the linux TSC syncing code, and use it
> > >to decide whether or not set kern.timecounter.smp_tsc=1? Would you
> > >object to that?
> >
> > Yes, I would object to that.
> >
> > Even to this day new CPU c
Hi
I have a problem that i hope that someone can help me with. I'm trying to
make a computer running a webserver, reachable on a net wich it don't own
an address on. In order to let clients reach the server, I use BPF to
capture the packets to an address that i have chosen, ( not important wich
ad
Poul-Henning Kamp writes:
> In message <[EMAIL PROTECTED]>, Andrew Gallatin
> writes:
> >
> >Poul-Henning Kamp writes:
> > > The best compromise solution therefore is to change the scheduler
> > > to make decisions based on the TSC ticks (or equivalent on other
> > > archs) and at regular
Hey all,
I been doing some network benchmarking using netperf and just simple
'fetch' on a new network setup to make sure I am getting the most out of
the router and servers, I thought I would post some results in case
some one can help me with my problems or if others are just interested
to
In message <[EMAIL PROTECTED]>, Andrew Gallatin
writes:
>
>Poul-Henning Kamp writes:
> > The best compromise solution therefore is to change the scheduler
> > to make decisions based on the TSC ticks (or equivalent on other
> > archs) and at regular intervals figure out how fast the CPU ran in
> >
Mike Silbersack <[EMAIL PROTECTED]> writes:
> On Fri, 14 Oct 2005, [EMAIL PROTECTED] wrote:
>
>> Nicolas KOWALSKI wrote:
>>> Our FreeBSD 4.10 NFS server has some problems serving files by NFS
>>> on TCP (no problem with UDP) when the Linux (2.6) or Solaris (5.9)
>>> clients shut down in an unclean
Poul-Henning Kamp writes:
> The best compromise solution therefore is to change the scheduler
> to make decisions based on the TSC ticks (or equivalent on other
> archs) and at regular intervals figure out how fast the CPU ran in
> the last period and convert the TSC ticks accumulated to a tim
Colleagues,
since there were a lot of em(4) related discussions on list, I
decided to forward this commit mail here.
This change should fix a big problem in if_em(), that you may
have experienced. If you experience long wedges in receive part,
for about minute or more, than you should try th
In message <[EMAIL PROTECTED]>, Bruce Evans writes:
>On Fri, 14 Oct 2005, Poul-Henning Kamp wrote:
>
>> In message <[EMAIL PROTECTED]>, Andrew Gallatin
>> writes:
>>
>>> Linux already takes care of syncing the TSC between SMP cpus, so we
>>> know it is possible. This seems like a much more doable
On Fri, 14 Oct 2005, [EMAIL PROTECTED] wrote:
Nicolas KOWALSKI wrote:
Our FreeBSD 4.10 NFS server has some problems serving files by NFS on
TCP (no problem with UDP) when the Linux (2.6) or Solaris (5.9)
clients shut down in an unclean manner (power failure). When the clients
try to mount the
On Fri, 14 Oct 2005, Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Andrew Gallatin
writes:
Linux already takes care of syncing the TSC between SMP cpus, so we
know it is possible. This seems like a much more doable optimization.
And it is likely to have other benefits..
The times
Nicolas KOWALSKI wrote:
Our FreeBSD 4.10 NFS server has some problems serving files by NFS on
TCP (no problem with UDP) when the Linux (2.6) or Solaris (5.9)
clients shut down in an unclean manner (power failure). When the
clients try to mount the shares from the server after an
unclean shutdow
In message <[EMAIL PROTECTED]>, Andrew Gallatin
writes:
>Linux already takes care of syncing the TSC between SMP cpus, so we
>know it is possible. This seems like a much more doable optimization.
>And it is likely to have other benefits..
Validating that the TSC is reliable is a nontrivial task
Hello,
This is a repost of a question I sent to freebsd-questions 10 days ago.
I "crosspost" it to freebsd-fs and freebsd-net, because the question is
about both...
Our FreeBSD 4.10 NFS server has some problems serving files by NFS on
TCP (no problem with UDP) when the Linux (2.6) or Solaris (
30 matches
Mail list logo
