Re: rebooting problem

[Peter Jeremy]

On Fri, 2005-Jun-17 11:58:35 +0200, GMane wrote:
>When I try to reboot my machine it hangs on and I have to do it manually 
>pressing the reset button.
>
>Did anyone have the same problem?

I've seen something similar on a HP DL380.  Do you have any modules
loaded?  If so, does the problem go away if you avoid loading any
modules?  See http://www.FreeBSD.org/cgi/query-pr.cgi?pr=i386/72441

-- 
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

kernel panic with cdrecord

[Zoran Kolic]

Dear all!
After moving to amd64 system (64-bit),
I have problem writing cd with cdrecord.
Release 5.4
Nec 3520a (dvd writer)
CDrtools-2.01
Whatever I do with cdrecord, it panics with
"fatal trap 9" message. First few lines, not
from kernel say that it is not the right
cdrecord and I need "pro-dvd" version.
After the "9" trap, says it's general
protection faulth while in kernel mode.
Gives instruction and other pointers add-
resses and, finaly, reboots.
Dvd-s are writen perfect, using growisofs.
Device reads all media with no mistake.
Just few weeks ago, it makes cd-s nice,
on i386 system. That machine had electric
issue and almost all stuff gone. Now, it
looks like cdrecord issue, but could be
also hardware failure.
Has someone any clue for this?
Best regards

 Zoran

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Peter Jeremy]

On Fri, 2005-Jun-17 23:42:08 +0200, Wilko Bulte wrote:
>On Fri, Jun 17, 2005 at 02:26:48PM -0700, Javier Henderson wrote..
>> Wilko Bulte wrote:
>> >Yes.  Go and visit the London City and check their computer rooms.  
>> >You will be surprised about the number of UNIX boxes.  You don't
>> >think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..?
>> 
>> But are those Unix servers actually processing bank transactions and 
>> holding customer accounts?

Unix and mainframes are not mutually exclusive - the major mainframe
vendors will be happy to supply Unix on their mainframes.  The big
benefit of mainframes is data integrity - your typical mainframe will
have error detection and/or correction on _all_ data paths, including
through the ALU, all levels of cache and all I/O paths.  The other
benefit of mainframes is massive I/O bandwidth and the ability to
usefully use the available bandwidth.

>Why not?   As an aside:  what do you think telecom operators run their
>main billing systems on?  UNIX...  Any idea what downtime costs per hour
>on those systems?  

Not just billing systems.  My employer sells Unix systems used for
call processing (intelligent networks) as well as PABX's built on Unix
kernels.  And downtime at the call processing end is more expensive
than the billing end - customers won't notice if the bill is ½hr late
(or a call is undercharged) but they do notice if they can't ring the
home-delivery pizza shop when they're hungry.

I think this is getting somewhat off-topic: I don't think any banks or
telcos have business critical systems running on FreeBSD or Linux with
MySQL databases.  And the FreeBSD-S/390 port is nowhere near Tier-1
status yet.

-- 
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

tty and serial console com port

[snort Snort]

Hi,

I just read thru the tty.h file and the tty command,
and have a feeling that the tty command and the tty.h
file does not handle the serial console com port
directly.

Can anyone tell me which part of the tty source does
invoke serial console com port?

Thanks
Sam

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: What is considered "the best supported" RAID controller for 5.x?

[Mike Tancsa]

At 08:41 PM 17/06/2005, Marc G. Fournier wrote:

The subject says it all ... I'm looking a new server, and right now have 
built it around the SRCZCRX PCI-X 128MB, since I've had good luck with the 
Intel RAID controllers with 4.x, and I *really* like the storcon CLI 
utility ... but, with the move to 5.x, I'm wondering if there is something 
else I should be looking at, or is this still a good card to go with?


I still like the 3ware cards for RAID1.  However, I have started using the 
Areca cards so far with good results on RAID5 machines.  There is both an 
http and cli app and the cards are VERY fast on the tests I have done.  See 
the arcmsr driver man page.


---Mike 


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Peter Jeremy]

On Fri, 2005-Jun-17 10:38:34 -0400, David Sze wrote:
>It turns out that the problem was the same thing everyone usually points 
>the finger at, but no one actually mentioned this time:  Linux mounts its 
>partitions async by default.

This shouldn't be an issue here.  The FreeBSD default has always been
that data is written asynchronously (see below) and there should be
virtually no metadata updates in a database application.  If an
application needs control over when the data is physically written to
the disk (eg a database server), it needs to use fsync(2) and/or
msync(2) calls.  If Linux (or FreeBSD) isn't complying with fsync(2)
or msync(2) semantics then it has a serious problem.

>super-smack select-key
>5.4-RELEASE ~20,000 queries/second
>6.0-CURRENT ~24,000 queries/second
>CentOS w/async  ~36,000 queries/second
>CentOS w/sync   ~26,000 queries/second

I can't see where this benchmark is doing any writes so I'd like to see
an explanation of the difference in CentOS performance figures before
making any decision on CentOS vs FreeBSD.

>super-smack update-select
>5.4-RELEASE ~4,000 queries/second
>6.0-CURRENT ~4,500 queries/second
>CentOS w/async  ~7,500 queries/second
>CentOS w/sync   ~750 queries/second
>
>That last CentOS number is not a typo, it was an order of magnitude 
>slower.

That's a surprising difference - I wouldn't have expected it to be
so large.

A couple of people have mentioned the impact of journalling.
Journalling improves performance by converting time-critical random
I/Os into time-critical sequential I/Os and background random I/Os -
and sequential I/O is many orders of magnitude faster than random I/O.
All transactional databases do their own journalling (REDO logs).  As
long as the database correctly issues filesystem synchronisation
commands and the filesystem correctly implements them, database
application, a journalling filesystem provides no benefits.

A more interesting test would be a client that issues a series of
updates to a server and, immediately after receiving the acknowledge
for the last update turns, off the server's power.  After the server
is rebooted, confirm that all the updates have been applied correctly.

Filesystem I/O behaviour:

DataMetadata   Mount type
asyncasync async
async sync 'traditional' UFS
asyncasync[*]  UFS + softupdates
 sync sync sync

'Metadata' covers directory updates and some inode updates

[*] softupdates controls write ordering to ensure on-disk consistency.

-- 
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Weird fdisk behavior

[Baldur Gislason]

I am trying to add another partition to my root drive, it has a few gigabytes 
of unpartitioned space.
Whenever I try to run fdisk -u it says cannot open disk /dev/ad0: No such file 
or directory
ad0 does exist, why does fdisk say otherwise? fdisk can display the partition 
table but it can't alter it.
securelevel is -1 and this is FreeBSD 5.4-STABLE from the beginning of May this 
year.

Baldur

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

What is considered "the best supported" RAID controller for 5.x?

[Marc G. Fournier]

The subject says it all ... I'm looking a new server, and right now have 
built it around the SRCZCRX PCI-X 128MB, since I've had good luck with the 
Intel RAID controllers with 4.x, and I *really* like the storcon CLI 
utility ... but, with the move to 5.x, I'm wondering if there is something 
else I should be looking at, or is this still a good card to go with?


Thanks ...


Marc G. Fournier   Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED]   Yahoo!: yscrappy  ICQ: 7615664
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: WAS: FreeBSD MySQL still WAY slower than Linux

[Matthias Buelow]

Julian Elischer <[EMAIL PROTECTED]> writes:

>Hmmm we processed something over a trillion dollars in bank backends 
>last year on
>FreeBSD 4.8 (plus patches)  on rack mounted PCs.
>And we didn't lose any of them (the dollars that is).

Ah! And look where the dollar is now! ;-)

mkb.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Don Lewis]

On 17 Jun, David Sze wrote:

> AFAIK, SCSI disks normally have write caching disabled.

All the ones that I've encountered in recent years have had write
caching enabled.  I always have to remember to use camcontrol to disable
WCE when I install a new disk.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 5.4-p1 crash

[Kris Kennaway]

On Fri, Jun 17, 2005 at 03:23:19PM -0700, Mitch Parks wrote:
> Below are details regarding another crash on a Dell 2600 SMP (HTT and USB 
> disabled). It has been 9 days since the last crash. I didn't have the 
> serial console in place for this last crash, but it is now.
> 
> Text includes:
> 1. backtrace
> 2. dmesg
> 3. kernel conf
> 
> Since Dell diagnostics and Memtest check out fine, I'm kind of between a 
> rock and a hard place here. I have a similar 2600 running 4.9 that is 
> working great. I'd welcome any advice.

Unfortunately this is a known bug in FreeBSD; check the archives for
more discussion.  Doug White tried to look at fixing it before
5.4-RELEASE but I think he gave up.

Kris


pgpgv7IIRvPJw.pgp
Description: PGP signature

Re: FreeBSD MySQL still WAY slower than Linux

[jonathan michaels]

matthias,

On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote:
> Wilko Bulte <[EMAIL PROTECTED]> writes:
> 
> >If you give me $5 per Unix system found there I can retire here and now.
> 
> For financial transaction processing, and the customer's accounts?
> I hope it's not my bank..

i know i'm not so well thought of around these parts .. but for my
$AUD0.02 worth.

my last two contracts, believe it or not i was a systems analyst for
some 12 years before i was retired out of my last contract to become a
permanently disabled man, now on permanent disability welfare. the
nature of my disabilites leaves me with impeared communications skills
and severe chronic pain, for which i take lareg quantities of very
heavy duty analgesics .. whchi also impear teh (already impearde)
communications skills.

i'm writing to let you know that two of australias largest banks not
only run whooping great mainframes but also run mainframe UNIX, no not
linux but commercial UNIX and for the 6 plus years i worked in teh
backoffice in a development on a cash management tool the only errors i
saw the mainfreme and its unix operating system make were directly
attributable to human errors .. mainly misskeying on teh transactions
scripts or latter when teh "OCR" readers didn't deccipher the humans
handwriting on teh transactons slipps. also but in teh lmosta rare as
hens teeth was a poorly MICR encoded transaction script that gage
ambigious results on multiple passes through the decoder that lead to
poor quality data.

umm yes computers make mistakes, and mainframes make bigger mistakes,
and unix makes really big mistakes but its usually the case that its
been told precisely to do that, whchis wrong by its human handler.

please note: i'm not putting teh tellers and data operatiors on teh
freing line. its teh banks management that loking to squeeze every last
drop of profit from n aging, ols and creaking system thats making all
these so called "computer errors" .. its so easy to accuse somebody or
thing when its not able (or given a chance) to defend itself.

sory i;m starting to mount my soap box here ..

tak care matthias mainframes are only very big unix boxen in desguise.

best wish and most warm regards

jonathan

-- 

powered by ..
QNX, OS9 and freeBSD  --  http://caamora com au/operating system
 === appropriate solution in an inappropriate world === 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

5.4-p1 crash

[Mitch Parks]

Below are details regarding another crash on a Dell 2600 SMP (HTT and USB 
disabled). It has been 9 days since the last crash. I didn't have the serial 
console in place for this last crash, but it is now.


Text includes:
1. backtrace
2. dmesg
3. kernel conf

Since Dell diagnostics and Memtest check out fine, I'm kind of between a 
rock and a hard place here. I have a similar 2600 running 4.9 that is 
working great. I'd welcome any advice.


Mitch Parks
IT Coordinator
UI Student Affairs

## 1

This GDB was configured as "i386-marcel-freebsd".
#0  doadump () at pcpu.h:159
159 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) backtrace
#0  doadump () at pcpu.h:159
#1  0xc05357d7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
#2  0xc0535afd in panic (fmt=0xc068b04f "%s")
at /usr/src/sys/kern/kern_shutdown.c:566
#3  0xc06632d4 in trap_fatal (frame=0xe9137978, eva=1117174480)
at /usr/src/sys/i386/i386/trap.c:817
#4  0xc0663017 in trap_pfault (frame=0xe9137978, usermode=0, eva=1117174480)
at /usr/src/sys/i386/i386/trap.c:735
#5  0xc0662c71 in trap (frame=
  {tf_fs = -1068367848, tf_es = -384630768, tf_ds = 16777232, tf_edi =
-9741
04776, tf_esi = 1117174476, tf_ebp = -384599616, tf_isp = -384599644, tf_ebx
= -
1007283084, tf_edx = 1117174476, tf_ecx = -1066420548, tf_eax = 0, tf_trapno
= 1
2, tf_err = 2, tf_eip = -1068141554, tf_cs = 8, tf_eflags = 66054, tf_esp =
-1007283200, tf_ss = -1004205824}) at /usr/src/sys/i386/i386/trap.c:425
#6  0xc065130a in calltrap () at /usr/src/sys/i386/i386/exception.s:140
#7  0xc0520018 in fork1 (td=0xc3f61474, flags=89, pages=-384599580,
procp=0xc0564171) at atomic.h:154
#8  0xc0557362 in selwakeuppri (sip=0xc3f61474, pri=89)
at /usr/src/sys/kern/sys_generic.c:1056
#9  0xc0564171 in ttwakeup (tp=0x10206) at /usr/src/sys/kern/tty.c:2366
#10 0xc0562e18 in ttymodem (tp=0xc3f61400, flag=0)
at /usr/src/sys/kern/tty.c:1625
#11 0xc0566b03 in ptcopen (dev=0xc4250900, flag=3, devtype=8192, td=0x0)
at linedisc.h:136
#12 0xc04f9f66 in spec_open (ap=0xe9137a80)
at /usr/src/sys/fs/specfs/spec_vnops.c:207
#13 0xc04f9cab in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:118
#14 0xc059489d in vn_open_cred (ndp=0xe9137be4, flagp=0xe9137ce4, cmode=0,
cred=0xc3891e00, fdidx=0) at vnode_if.h:228
#15 0xc0594482 in vn_open (ndp=0x0, flagp=0xe9137ce4, cmode=0, fdidx=3)
at /usr/src/sys/kern/vfs_vnops.c:91
#16 0xc058e32f in kern_open (td=0xc468e900, path=0x0, pathseg=UIO_USERSPACE,

flags=3, mode=0) at /usr/src/sys/kern/vfs_syscalls.c:957
#17 0xc058e240 in open (td=0xc468e900, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:926
#18 0xc066360f in syscall (frame=
  {tf_fs = 47, tf_es = 134676527, tf_ds = -1078001617, tf_edi = -1,
tf_esi =
 671951917, tf_ebp = -1077943096, tf_isp = -384598668, tf_ebx = 671959136,
tf_ed
x = 671951953, tf_ecx = 674495244, tf_eax = 5, tf_trapno = 12, tf_err = 2,
tf_eip = 674002619, tf_cs = 31, tf_eflags = 658, tf_esp = -1077943188, tf_ss
= 47})
at /usr/src/sys/i386/i386/trap.c:1009
#19 0xc065135f in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:201
#20 0x002f in ?? ()
#21 0x0807002f in ?? ()
#22 0xbfbf002f in ?? ()
#23 0x in ?? ()
#24 0x280d2c2d in ?? ()
#25 0xbfbfe4c8 in ?? ()
#26 0xe9137d74 in ?? ()
#27 0x280d4860 in ?? ()
#28 0x280d2c51 in ?? ()
#29 0x2833fb0c in ?? ()
#30 0x0005 in ?? ()
#31 0x000c in ?? ()
#32 0x0002 in ?? ()
#33 0x282c76bb in ?? ()
#34 0x001f in ?? ()
#35 0x0292 in ?? ()
#36 0xbfbfe46c in ?? ()
#37 0x002f in ?? ()
#38 0x08067000 in ?? ()
#39 0x0004 in ?? ()
#40 0x in ?? ()
#41 0x in ?? ()
#42 0x5b77b000 in ?? ()
#43 0xc42361c4 in ?? ()
#44 0xc468e900 in ?? ()
#45 0xe9137b34 in ?? ()
#46 0xe9137b1c in ?? ()
#47 0xc347f600 in ?? ()
#48 0xc0545d9f in sched_switch (td=0x280d2c2d, newtd=0x280d4860,
flags=Cannot access memory at address 0xbfbfe4d8
)
at /usr/src/sys/kern/sched_4bsd.c:881
Previous frame inner to this frame (corrupt stack?)

# 2

Copyright (c) 1992-2005 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.4-RELEASE-p1 #18: Thu May 26 23:37:44 PDT 2005
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/kuoi
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2791.01-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0xf29  Stepping = 9
  
Features=0xbfebfbff
real memory  = 2147287040 (2047 MB)
avail memory = 2095947776 (1998 MB)
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  6
ioapic0: Changing APIC ID to 8
ioapic1: Changing APIC ID to 9
ioapic2: Changing APIC ID to 10
ioapic2: WARNING: intbase 72 != expected base 48
ioapic3: Changing APIC ID to 11
ioapic3: WARNING: intbase 120 != expected base 96
ioapic4: Changing APIC ID

Re: FreeBSD MySQL still WAY slower than Linux

[Jarrod Martin]

Wilko Bulte wrote:


On Fri, Jun 17, 2005 at 11:26:56PM +0200, Owe Andr? J?rgensen wrote..
 


Wilko Bulte wrote:
   


On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote..

 


Wilko Bulte <[EMAIL PROTECTED]> writes:


   


If you give me $5 per Unix system found there I can retire here and now.
 


For financial transaction processing, and the customer's accounts?
   

Yes.  Go and visit the London City and check their computer rooms.  
You will be surprised about the number of UNIX boxes.  You don't

think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..?


 


I hope it's not my bank..
   


It might very well be your bank..

 

I'm sorry to say it, but there is a lot of mainframes a quite few unix 
boxes in the central accounting and transfer departments.


remember that there are a shitload of Cobol Mainframes that are still 
used by a lot of banks..
   



Sure.  But that does not mean there are not a lot of UNIX machines carrying
high-value financial data in the banking world.

What we forgot:  there are quite some Tandem boxes too, for things like
dealing rooms and ATM networks etc.

 

this is a FreeBSD vs Linux MySQL performance thread.  not a pissing 
contest about banking mainframes...

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: WAS: FreeBSD MySQL still WAY slower than Linux

[Julian Elischer]

Wilko Bulte <[EMAIL PROTECTED]> writes:

 


If you give me $5 per Unix system found there I can retire here and now.
   

For financial transaction processing, and the customer's accounts? I 
hope it's not my bank.. mkb.



Hmmm we processed something over a trillion dollars in bank backends 
last year on

FreeBSD 4.8 (plus patches)  on rack mounted PCs.
And we didn't lose any of them (the dollars that is).




___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Matthias Buelow]

Andreas Braukmann <[EMAIL PROTECTED]> writes:

>no. But I don't mount them "async", either.
>The default "noasync" in combination with softupdates
>on disks with disabled write caches is perfectly fine
>with me.

"Noasync" only makes sense in the absence of softupdates. With
softupdates, metadata is written asynchronously (I mean, that's the
whole point, or at least half of it.)

Besides, I thought you were talking about synchronous mounts (i.e.,
synchronous metadata _and_ data writes, which for most uses are just
impractical).

mkb.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Wilko Bulte]

On Fri, Jun 17, 2005 at 02:47:54PM -0700, Javier Henderson wrote..
> Wilko Bulte wrote:
> >On Fri, Jun 17, 2005 at 02:26:48PM -0700, Javier Henderson wrote..
> >
> >>Wilko Bulte wrote:
> >>
> >>>On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote..
> >>>
> >>>
> Wilko Bulte <[EMAIL PROTECTED]> writes:
> 
> 
> 
> >If you give me $5 per Unix system found there I can retire here and 
> >now.
> 
> For financial transaction processing, and the customer's accounts?
> >>>
> >>>
> >>>Yes.  Go and visit the London City and check their computer rooms.  
> >>>You will be surprised about the number of UNIX boxes.  You don't
> >>>think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..?
> >>
> >>But are those Unix servers actually processing bank transactions and 
> >>holding customer accounts?
> >
> >
> >Why not?   As an aside:  what do you think telecom operators run their
> >main billing systems on?  UNIX... 
> 
> I'm sure some do. Others run theirs on VMS.

Most run Tru64.  Not a lot run VMS.  We had stock exchanges run VMS.
Like the Dutch Stock Exchange and the Australian one for example.  

> >Any idea what downtime costs per hour on those systems?  
> 
> A lot.
> 
> -jav
> 
> 
--- end of quoted text ---

-- 
Wilko Bulte [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Andreas Braukmann]

--On Freitag, 17. Juni 2005 23:10 Uhr +0200 Matthias Buelow <[EMAIL PROTECTED]> 
wrote:


Andreas Braukmann <[EMAIL PROTECTED]> writes:


That makes your arguments pointless. I wouldn't even think of
running a database server on an async mounted filesystem; all the
more I wouldn't connect a drive with enabled write cache to a
production box.


So you remount all filesystems -o sync on your FreeBSD servers?
And you're still satisfied with the performance?


no. But I don't mount them "async", either.
The default "noasync" in combination with softupdates
on disks with disabled write caches is perfectly fine
with me.


-Andreas




___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Javier Henderson]

Wilko Bulte wrote:

On Fri, Jun 17, 2005 at 02:26:48PM -0700, Javier Henderson wrote..


Wilko Bulte wrote:


On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote..



Wilko Bulte <[EMAIL PROTECTED]> writes:




If you give me $5 per Unix system found there I can retire here and now.


For financial transaction processing, and the customer's accounts?



Yes.  Go and visit the London City and check their computer rooms.  
You will be surprised about the number of UNIX boxes.  You don't

think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..?


But are those Unix servers actually processing bank transactions and 
holding customer accounts?



Why not?   As an aside:  what do you think telecom operators run their
main billing systems on?  UNIX... 


I'm sure some do. Others run theirs on VMS.

Any idea what downtime costs per hour on those systems?  


A lot.

-jav



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Chuck Swiger]

Javier Henderson wrote:

Wilko Bulte wrote:

[ ... ]
Yes.  Go and visit the London City and check their computer rooms.  
You will be surprised about the number of UNIX boxes.  You don't

think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..?


But are those Unix servers actually processing bank transactions and 
holding customer accounts?


Some of 'em, sure.  They tended to use a lot of Sun E or HP Apollo 9000 
boxen.  They also used Unix boxes a lot for trading system/forecasting, often 
using inhouse software development and a bit of outside  consulting.  At one 
point, SBC had over 3000 NeXT systems there.


[ I worked at a company which developed and deployed NEXTSTEP software for the 
various big banks in Chicago, FNBC, SBC, UBS, and the CBX (commodity exchange). 
 ITS, run by a guy called Ted Shelton. ]


--
-Chuck

PS: You'd be surprised at how many ATMs and POS machines are running IBM's 
OS/2

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Wilko Bulte]

On Fri, Jun 17, 2005 at 02:26:48PM -0700, Javier Henderson wrote..
> Wilko Bulte wrote:
> >On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote..
> >
> >>Wilko Bulte <[EMAIL PROTECTED]> writes:
> >>
> >>
> >>>If you give me $5 per Unix system found there I can retire here and now.
> >>
> >>For financial transaction processing, and the customer's accounts?
> >
> >
> >Yes.  Go and visit the London City and check their computer rooms.  
> >You will be surprised about the number of UNIX boxes.  You don't
> >think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..?
> 
> But are those Unix servers actually processing bank transactions and 
> holding customer accounts?

Why not?   As an aside:  what do you think telecom operators run their
main billing systems on?  UNIX...  Any idea what downtime costs per hour
on those systems?  

-- 
Wilko Bulte [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Wilko Bulte]

On Fri, Jun 17, 2005 at 11:26:56PM +0200, Owe Andr? J?rgensen wrote..
> Wilko Bulte wrote:
> >On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote..
> >
> >>Wilko Bulte <[EMAIL PROTECTED]> writes:
> >>
> >>
> >>>If you give me $5 per Unix system found there I can retire here and now.
> >>
> >>For financial transaction processing, and the customer's accounts?
> >
> >
> >Yes.  Go and visit the London City and check their computer rooms.  
> >You will be surprised about the number of UNIX boxes.  You don't
> >think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..?
> >
> >
> >>I hope it's not my bank..
> >
> >
> >It might very well be your bank..
> >
> I'm sorry to say it, but there is a lot of mainframes a quite few unix 
> boxes in the central accounting and transfer departments.
> 
> remember that there are a shitload of Cobol Mainframes that are still 
> used by a lot of banks..

Sure.  But that does not mean there are not a lot of UNIX machines carrying
high-value financial data in the banking world.

What we forgot:  there are quite some Tandem boxes too, for things like
dealing rooms and ATM networks etc.

-- 
Wilko Bulte [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Matthias Buelow]

Wilko Bulte <[EMAIL PROTECTED]> writes:

>Yes.  Go and visit the London City and check their computer rooms.  
>You will be surprised about the number of UNIX boxes.  You don't
>think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..?

And these are the machines where the master account data is stored?

>It might very well be your bank..

I've browsed a bit.. they seem to be using one (or more) S/390
(zSeries). Although a different branch office indeed seems to have
replaced it for a couple pSeries machines with AIX and some Veritas
clusters but I don't know what the purpose of this installation is. But
in general I'd think that mainframes are still dominant here. From what
I've heard, all transactions are also printed, in real-time, on paper
(by high-speed lineprinters), so that even when the machines fail
completely and lose transaction data, there is still a hardcopy log. At
least I hope that this is (still) true.

mkb.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Javier Henderson]

Wilko Bulte wrote:

On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote..


Wilko Bulte <[EMAIL PROTECTED]> writes:



If you give me $5 per Unix system found there I can retire here and now.


For financial transaction processing, and the customer's accounts?



Yes.  Go and visit the London City and check their computer rooms.  
You will be surprised about the number of UNIX boxes.  You don't

think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..?


But are those Unix servers actually processing bank transactions and 
holding customer accounts?


-jav
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Owe André Jørgensen]

Wilko Bulte wrote:

On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote..


Wilko Bulte <[EMAIL PROTECTED]> writes:



If you give me $5 per Unix system found there I can retire here and now.


For financial transaction processing, and the customer's accounts?



Yes.  Go and visit the London City and check their computer rooms.  
You will be surprised about the number of UNIX boxes.  You don't

think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..?



I hope it's not my bank..



It might very well be your bank..



>

I'm sorry to say it, but there is a lot of mainframes a quite few unix 
boxes in the central accounting and transfer departments.


remember that there are a shitload of Cobol Mainframes that are still 
used by a lot of banks..

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Wilko Bulte]

On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote..
> Wilko Bulte <[EMAIL PROTECTED]> writes:
> 
> >If you give me $5 per Unix system found there I can retire here and now.
> 
> For financial transaction processing, and the customer's accounts?

Yes.  Go and visit the London City and check their computer rooms.  
You will be surprised about the number of UNIX boxes.  You don't
think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..?

> I hope it's not my bank..

It might very well be your bank..

-- 
Wilko Bulte [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Matthias Buelow]

Wilko Bulte <[EMAIL PROTECTED]> writes:

>If you give me $5 per Unix system found there I can retire here and now.

For financial transaction processing, and the customer's accounts?
I hope it's not my bank..

mkb.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Matthias Buelow]

Andreas Braukmann <[EMAIL PROTECTED]> writes:

>That makes your arguments pointless. I wouldn't even think of
>running a database server on an async mounted filesystem; all the
>more I wouldn't connect a drive with enabled write cache to a
>production box.

So you remount all filesystems -o sync on your FreeBSD servers?
And you're still satisfied with the performance?

mkb.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Wilko Bulte]

On Fri, Jun 17, 2005 at 11:01:30PM +0200, Matthias Buelow wrote..
> David Sze <[EMAIL PROTECTED]> writes:
> 
> >I'm not sure filesystem consistency alone is "good enough".  Say your
> >bank's database crashes right after you make a deposit.  When it comes
> >back up it's consistent, but only up to 5 minutes before the crash due
> >to the async mount.
> 
> A bank doesn't run on Unix. It runs on mainframes, with such funny

Total bull..

> features like processors executing each instruction in parallel, 
> and comparing the results. Completely different universe here.

Sorry, when was the last time you saw a bank backoffice computer room?

If you give me $5 per Unix system found there I can retire here and now.

-- 
Wilko Bulte [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Matthias Buelow]

David Sze <[EMAIL PROTECTED]> writes:

>I'm not sure filesystem consistency alone is "good enough".  Say your
>bank's database crashes right after you make a deposit.  When it comes
>back up it's consistent, but only up to 5 minutes before the crash due
>to the async mount.

A bank doesn't run on Unix. It runs on mainframes, with such funny
features like processors executing each instruction in parallel, 
and comparing the results. Completely different universe here.

On Unix, filesystem consistency is the best you'll normally get. You
_can_ mount filesystems synchronously, both with UFS aswell as ext2/3
etc., but the performance is abysmal. Maybe useful in particular
situations but you probably wouldn't want to run your desktop (or busy
server) with it. I mean, just try it and see (and make sure
writeback-caching on the disks is disabled, when possible.)

mkb.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Andreas Braukmann]

--On Freitag, 17. Juni 2005 17:47 Uhr +0200 Matthias Buelow <[EMAIL PROTECTED]> 
wrote:


Greg Barniskis <[EMAIL PROTECTED]> writes:



Is CentOS using ext2? I thought everyone moved to ext3 already, which
provides nearly the speed of ext2+async but is safe due to its journal.
If you make such comparisons, please use current technology, and not
the status quo of 5 years ago.


ext3 delivers abysmal performance on concurrent write operations.
XFS is substantially faster. We experienced postgresql database
files becoming corrupt under high load (bulk imports; more than
a hand full updates per second) on xfs fileystems (2.6.3 - 2.6.5
timeframe).

We're about to move this client's (a pure Linux shop as yet)
postgresql servers to FreeBSD/amd64.
The first experimental setup on FreeBSD/amd64 (single processor,
1.4 GHz, 2 single SCSI disks 10kUPM, 5-stable, SMP-Kernel) delivers
the quintupled (application specific) insert/update throughput
over the current production setup (dual XEON, 4 spindle Hardware
RAID 1+0, Linux/i386 2.6.x SMP).

I hope to get my hands on a larger hardware testbed, so that I'd
be able to do side by side comparisons.



[Apart from that, over the last decade, I've lost more UFS filesystems
than ext2, so at least for me, that purported unsafety of ext2+async
mounts is theoretical at best. In the end, with today's write-caches
usually enabled, both are essentially the same, anyways.]


That makes your arguments pointless. I wouldn't even think of
running a database server on an async mounted filesystem; all the
more I wouldn't connect a drive with enabled write cache to a
production box.



-Andreas

I lost exactly two UFS filesystems since my very FreeBSD beginnings
and that was in the very early 3-current days shortly after the
very first softupdates patches ...

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Steve O'Hara-Smith]

On Fri, 17 Jun 2005 13:57:26 -0500
David Sze <[EMAIL PROTECTED]> wrote:

> I'm not sure filesystem consistency alone is "good enough".  Say your
> bank's database crashes right after you make a deposit.  When it comes
> back up it's consistent, but only up to 5 minutes before the crash due
> to the async mount.
> 
> For this type of application, something in the system has to be keeping
> a "journal" on a sync mount in order for recovery to be both consistent
> and correct.

For that critical an application the transaction should be stored
in multiple physically separated locations and confirmed by the two faced
kermit\w\w\w two phase commit protocol. Said implementation had better have
the correct disaster restart protocol implemented too.

-- 
C:>WIN  |   Directable Mirror Arrays
The computer obeys and wins.| A better way to focus the sun
You lose and Bill collects. |licences available see
|http://www.sohara.org/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[David Sze]

On Fri, Jun 17, 2005 at 06:20:59PM +0200, Matthias Buelow wrote:
> David Sze <[EMAIL PROTECTED]> writes:
> 
> >CentOS uses ext3 by default.  How does having a journal help if the
> >journal is stored on the same async filesystem?  Unless the journal
> >writes are guaranteed sync.
> 
> The journal guarantees that the filesystem will always be consistent. If
> a journal entry doesn't make it to disk, the operation has never
> happened; and the journal entry won't get removed, until the metadata
> update has been performed. So the worst thing that could happen is, that
> the same operation will be performed twice, once normally, and once at
> log replay on reboot. This is not an issue, since such metadata
> operations (delete file from directory, write a value into superblock,
> etc.) are usually idempotent.
> 
> That's the basic function of all journalled filesystems, and that's why
> you don't need to run fsck on them. You don't need to write the journal
> synchronously, you can do these things in groups.
> 
> The softupdates mechanism does something similar; only it doesn't
> maintain an on-disk journal, and hence needs fsck after boot to fix up
> the free block bitmaps and stuff (basically performing a garbage
> collection on the filesystem, which, unfortunately, is pretty slow).


I'm not sure filesystem consistency alone is "good enough".  Say your
bank's database crashes right after you make a deposit.  When it comes
back up it's consistent, but only up to 5 minutes before the crash due
to the async mount.

For this type of application, something in the system has to be keeping
a "journal" on a sync mount in order for recovery to be both consistent
and correct.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Thomas Hurst]

* David Sze ([EMAIL PROTECTED]) wrote:

> super-smack select-key
> 5.4-RELEASE ~20,000 queries/second
> 6.0-CURRENT ~24,000 queries/second
> CentOS w/async  ~36,000 queries/second
> CentOS w/sync   ~26,000 queries/second

Uh, this should be an entirely cached set of reads, why does mounting
sync reduce performance this much?  Does FreeBSD see a similar boost
with async mounts?

> super-smack update-select
> 5.4-RELEASE ~4,000 queries/second
> 6.0-CURRENT ~4,500 queries/second
> CentOS w/async  ~7,500 queries/second
> CentOS w/sync   ~750 queries/second

Is this even relevent?  Async is by far the most common setup on Linux,
one which seems very stable and safe, especially on XFS/Reiser.  Of
course if FreeBSD can't match Linux/async performance, but still perform
like this on a potentially safer sync mount, that's fine by me, but I'm
having trouble buying that select-key performance.  Even standalone
multi-second and non-concurrent selects demonstrate this 30-40% lower
performance than Linux on the same hardware.

-- 
Thomas 'Freaky' Hurst
http://hur.st/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Enhance your sexual lifestyle!

[Dolores]

The good sex guide!
http://mbux.3i6ep43widlbp43.shieldha.com



HYBRID, n. A pooled issue.
We are the total of our longings.  
One more drink and I'll be under the host.



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Warner Losh]

> i think you're missing the point... using CURRENT on a production 
> machine is a bad idea...  the performance is great, but hardly worth the 
> risk of breaking something.

In general, this is true.  But since we're in the glide path to a
release, and since we have measures in place to keep destablizing
commits out of the tree, CURRENT these days isn't a scary place to be
if you validate the specific version of current you are deploying.
There's risks there, but it isn't like it was at the worst part of the
5.x release cycle where you counted yourself lucky if CURRENT booted
on your hardware and was still running the next day... 

Warner
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

shutdown -p now doesn't power off VMWare ESX 2.x VMs

[Tom Pepper]

I realize this is probably a VMware issue, but was wondering if  
anyone here has experience getting -stable to be happy on ESX 2.1.   
I've managed to get 8 VMs humming along and their agent software  
(incl. memory manager) functioning in 5.4, but am having difficulty  
getting a shutdown command from the ESX console to instantiate a  
shutdown in the FBSD VMs.  Likewise, issuing a shutdown -p now makes  
it all the way past halt but the host doesn't apparently interpret  
the power down signal.  Ideas?


Thanks much,
-t

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Matthias Buelow]

David Sze <[EMAIL PROTECTED]> writes:

>CentOS uses ext3 by default.  How does having a journal help if the
>journal is stored on the same async filesystem?  Unless the journal
>writes are guaranteed sync.

The journal guarantees that the filesystem will always be consistent. If
a journal entry doesn't make it to disk, the operation has never
happened; and the journal entry won't get removed, until the metadata
update has been performed. So the worst thing that could happen is, that
the same operation will be performed twice, once normally, and once at
log replay on reboot. This is not an issue, since such metadata
operations (delete file from directory, write a value into superblock,
etc.) are usually idempotent.

That's the basic function of all journalled filesystems, and that's why
you don't need to run fsck on them. You don't need to write the journal
synchronously, you can do these things in groups.

The softupdates mechanism does something similar; only it doesn't
maintain an on-disk journal, and hence needs fsck after boot to fix up
the free block bitmaps and stuff (basically performing a garbage
collection on the filesystem, which, unfortunately, is pretty slow).

mkb.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Greg Barniskis]

Matthias Buelow wrote:

Greg Barniskis <[EMAIL PROTECTED]> writes:


that async provides fast writes at the cost of "no guarantee at all 
for a consistent state of the filesystem". So, you choose: fast but 
not so reliable writes, or slower writes with fast, reliable 
disaster recovery.


Thanks to the FreeBSD team for choosing the sensible default, even 
if it results in the occasional "Linux is faster!" debate. Dang 
smirky penguins... you're flightless I tell ya, flightless. =)



Is CentOS using ext2? I thought everyone moved to ext3 already, which
provides nearly the speed of ext2+async but is safe due to its journal.
If you make such comparisons, please use current technology, and not
the status quo of 5 years ago.


OK, my bad. I did not do thorough research, just enough to satisfy 
my curiosity. If ext3 does well and safely, then more power to 'em. 
Anyway, sorry, what I wrote was not intended to be flame bait, just 
blowing off a little steam. I'll go crawl back under my rock now.


However, I stand by the assertion that a slow, certain default is 
better than a fast, uncertain one. That async was ever the Linux 
default is troubling (to me), and I've got plenty other reasons to 
prefer BSD over Linux (which is why I didn't do thorough research in 
the first place -- no interest at all in migrating, even if there's 
a database speed boost).


--
Greg Barniskis, Computer Systems Integrator
South Central Library System (SCLS)
Library Interchange Network (LINK)
, (608) 266-6348
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[David Sze]

On Fri, Jun 17, 2005 at 12:05:54PM -0400, JM wrote:
> David Sze wrote:
> >
> >Under normal circumstances I'd agree, but -CURRENT is already in code
> >freeze in preparation for the upcoming 6.0 release:
> >
> > http://www.freebsd.org/releases/6.0R/schedule.html
> >
> >I also follow the cvs-src mailing list pretty closely, and I like the
> >stability and performance increases that have gone into there.  It seems
> >like most of them won't be backported to RELENG_5 because they break ABI
> >compatibility.
> >
> >
> > 
> >
> code freeze != glitch free XD

RELENG_5_X, RELENG_5, RELENG_4_X, RELENG_4 != glitch free

Point being, in both cases the key is to follow the mailing lists, not
make decisions on what to use based solely on the way they're labelled.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

fxp0: discard oversize frame leads to icmp 36: ip reassembly time exceeded

[Bruce Ashfield]

Hi all,

I've been searching through archives and many freebsd resources and can't 
seem to find a solution to the problem that I'm currently seeing. I thought 
I'd check here before hacking the kernel to try and fix it myself, just in 
case the fix is already out there and just eluding me :)

I'm running a 5.4-STABLE freebsd firewall. Everything is pretty standard, 
DSL -> firewall -> clients. I'm using pppoe and providing NAT and other 
goodies to the machines behind the firewall. Nothing too fancy.

All my services are passing nicely through the firewall, except one 
application. VNC/Timbuktu when run over a VPN connection. I've been trying 
to fix the problem by restricting mtu size, I've got tcpmssfixup and have 
clamped the size on the client Window's box as well. Nothing works, but the 
symptom I was seeing and was trying to solve was:

> icmp 36: ip reassembly time exceeded

As dumped from tcpdump on my pppoe tunnel. I searched high and low and tried 
all kinds of tcp/ip tuning options. Nothing helped. So during yet another 
debugging session I noticed:

> fxp0: discard oversize frame (ether type 8864 flags 3 len 1470 > max 1462)

In my logs. Funny how that message matched the ip re-assembly errors 1 to 1. 
So it looks like my nic is dropping the packets as they are detected as too 
large and that propagates up and then I see my icmp message. Makes sense.

I've seen this problem mentioned in other freebsd forums, but I most often 
saw the answer "upgrade to the latest 5-release", which I *should* already 
be running. The message comes from /sys/net/if_ethersubr.c and obviously it 
is calculating the MAX size of the packet incorrectly or I've still got 
something misconfigured. I also poked around in the fxp driver, but didn't 
see anything obvious.

So before I go off doing some more extensive hacking, I thought I'd see if 
anyone could point me at the problem or maybe even show me the patch I 
couldn't find :)

I've included some potentially relevant dumps below,

Thanks,

Bruce

--

fwe0: flags=108943 mtu 1500
options=8
inet6 fe80::40:63ff:fe04:2c40%fwe0 prefixlen 64 scopeid 0x1
ether 02:40:63:04:2c:40
ch 1 dma 0
vr0: flags=8843 mtu 1448
inet6 fe80::240:63ff:fedd:622f%vr0 prefixlen 64 scopeid 0x2
inet 10.10.x.x netmask 0xff00 broadcast
10.255.255.255
ether 00:40:63:dd:62:2f
media: Ethernet autoselect (10baseT/UTP)
status: active
fxp0: flags=8843 mtu 1448
options=8
inet6 fe80::202:b3ff:fe24:8182%fxp0 prefixlen 64 scopeid 0x3
ether 00:02:b3:24:81:82
media: Ethernet autoselect (10baseT/UTP)
status: active
plip0: flags=108810 mtu 1500
lo0: flags=8049 mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
inet 127.0.0.1  netmask 0xff00
tun0: flags=8051 mtu 1448
inet 66.x.x.x --> 66.x.x.x netmask 0xff00
Opened by PID 222



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at 
its end"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[JM]

David Sze wrote:


On Fri, Jun 17, 2005 at 11:28:24AM -0400, JM wrote:
 

i think you're missing the point... using CURRENT on a production 
machine is a bad idea...  the performance is great, but hardly worth the 
risk of breaking something.
   



Under normal circumstances I'd agree, but -CURRENT is already in code
freeze in preparation for the upcoming 6.0 release:

http://www.freebsd.org/releases/6.0R/schedule.html

I also follow the cvs-src mailing list pretty closely, and I like the
stability and performance increases that have gone into there.  It seems
like most of them won't be backported to RELENG_5 because they break ABI
compatibility.


 


code freeze != glitch free XD
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[David Sze]

On Fri, Jun 17, 2005 at 05:47:56PM +0200, Matthias Buelow wrote:
> 
> Is CentOS using ext2? I thought everyone moved to ext3 already, which
> provides nearly the speed of ext2+async but is safe due to its journal.
> If you make such comparisons, please use current technology, and not
> the status quo of 5 years ago.

CentOS uses ext3 by default.  How does having a journal help if the
journal is stored on the same async filesystem?  Unless the journal
writes are guaranteed sync.


> [Apart from that, over the last decade, I've lost more UFS filesystems
> than ext2, so at least for me, that purported unsafety of ext2+async
> mounts is theoretical at best. In the end, with today's write-caches
> usually enabled, both are essentially the same, anyways.]

AFAIK, SCSI disks normally have write caching disabled.  Proper RAID
controllers also won't do write-back caching by default unless there's
a battery backup.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Matthias Buelow]

Greg Barniskis <[EMAIL PROTECTED]> writes:

>that async provides fast writes at the cost of "no guarantee at all 
>for a consistent state of the filesystem". So, you choose: fast but 
>not so reliable writes, or slower writes with fast, reliable 
>disaster recovery.
>
>Thanks to the FreeBSD team for choosing the sensible default, even 
>if it results in the occasional "Linux is faster!" debate. Dang 
>smirky penguins... you're flightless I tell ya, flightless. =)

Is CentOS using ext2? I thought everyone moved to ext3 already, which
provides nearly the speed of ext2+async but is safe due to its journal.
If you make such comparisons, please use current technology, and not
the status quo of 5 years ago.

[Apart from that, over the last decade, I've lost more UFS filesystems
than ext2, so at least for me, that purported unsafety of ext2+async
mounts is theoretical at best. In the end, with today's write-caches
usually enabled, both are essentially the same, anyways.]

mkb.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[David Sze]

On Fri, Jun 17, 2005 at 11:28:24AM -0400, JM wrote:
> i think you're missing the point... using CURRENT on a production 
> machine is a bad idea...  the performance is great, but hardly worth the 
> risk of breaking something.

Under normal circumstances I'd agree, but -CURRENT is already in code
freeze in preparation for the upcoming 6.0 release:

http://www.freebsd.org/releases/6.0R/schedule.html

I also follow the cvs-src mailing list pretty closely, and I like the
stability and performance increases that have gone into there.  It seems
like most of them won't be backported to RELENG_5 because they break ABI
compatibility.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Greg Barniskis]

J. T. Farmer wrote:

Uzi wrote:


[...]


super-smack select-key
5.4-RELEASE ~20,000 queries/second
6.0-CURRENT ~24,000 queries/second
CentOS w/async  ~36,000 queries/second
CentOS w/sync   ~26,000 queries/second

super-smack update-select
5.4-RELEASE ~4,000 queries/second
6.0-CURRENT ~4,500 queries/second
CentOS w/async  ~7,500 queries/second
CentOS w/sync   ~750 queries/second

That last CentOS number is not a typo, it was an order of magnitude 
slower.  I didn't try other file systems on CentOS, just the default 
ext3. It's possible that reiserfs or xfs might not be as affected by 
switching from async to sync.


So my production server is now happily running mysql 4.1 on 
6.0-CURRENT :).



I don't get it.
You get 30% less perfomance, running a non-production release for 
production, and happy about it?  




Try reading it again.  The last time I checked, 24k queries/sec _is_ 
faster than

20k queries/sec.  And 4.5k queries/sec is faster than 4.0k queries/sec.


I think he meant comparing 36,000 on CentOS (async) to 24,000 on 
CURRENT (sync). I wondered that myself, and having searched out the 
answer I find that it is declared in


http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-disk.html

that async provides fast writes at the cost of "no guarantee at all 
for a consistent state of the filesystem". So, you choose: fast but 
not so reliable writes, or slower writes with fast, reliable 
disaster recovery.


Thanks to the FreeBSD team for choosing the sensible default, even 
if it results in the occasional "Linux is faster!" debate. Dang 
smirky penguins... you're flightless I tell ya, flightless. =)



--
Greg Barniskis, Computer Systems Integrator
South Central Library System (SCLS)
Library Interchange Network (LINK)
, (608) 266-6348
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[JM]

J. T. Farmer wrote:


Uzi wrote:


[...]


super-smack select-key
5.4-RELEASE ~20,000 queries/second
6.0-CURRENT ~24,000 queries/second
CentOS w/async  ~36,000 queries/second
CentOS w/sync   ~26,000 queries/second

super-smack update-select
5.4-RELEASE ~4,000 queries/second
6.0-CURRENT ~4,500 queries/second
CentOS w/async  ~7,500 queries/second
CentOS w/sync   ~750 queries/second

That last CentOS number is not a typo, it was an order of magnitude 
slower.  I didn't try other file systems on CentOS, just the default 
ext3. It's possible that reiserfs or xfs might not be as affected by 
switching from async to sync.


So my production server is now happily running mysql 4.1 on 
6.0-CURRENT :).



I don't get it.
You get 30% less perfomance, running a non-production release for 
production, and happy about it?  




Try reading it again.  The last time I checked, 24k queries/sec _is_ 
faster than

20k queries/sec.  And 4.5k queries/sec is faster than 4.0k queries/sec.

John

i think you're missing the point... using CURRENT on a production 
machine is a bad idea...  the performance is great, but hardly worth the 
risk of breaking something.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[J. T. Farmer]

Uzi wrote:


[...]


super-smack select-key
5.4-RELEASE ~20,000 queries/second
6.0-CURRENT ~24,000 queries/second
CentOS w/async  ~36,000 queries/second
CentOS w/sync   ~26,000 queries/second

super-smack update-select
5.4-RELEASE ~4,000 queries/second
6.0-CURRENT ~4,500 queries/second
CentOS w/async  ~7,500 queries/second
CentOS w/sync   ~750 queries/second

That last CentOS number is not a typo, it was an order of magnitude 
slower.  I didn't try other file systems on CentOS, just the default 
ext3. It's possible that reiserfs or xfs might not be as affected by 
switching from async to sync.


So my production server is now happily running mysql 4.1 on 
6.0-CURRENT :).


I don't get it.
You get 30% less perfomance, running a non-production release for 
production, and happy about it?  



Try reading it again.  The last time I checked, 24k queries/sec _is_ 
faster than

20k queries/sec.  And 4.5k queries/sec is faster than 4.0k queries/sec.

John

--
John T. FarmerOwner & CTOGoldSword Systems
[EMAIL PROTECTED] 865-691-6498   Knoxville TN
   Consulting, Design, & Development of Networks & Software

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[JM]

David Sze wrote:


At 05:15 PM 16/06/2005 +0100, Steve Roome wrote this to All:


Thank you all for your suggestions on this thread, here's a brief
breakdown of most of the ideas from people:

Billy Newsom: COMPILER, DISK, MYSQLVERSION
Daniel Eischen: +/-HTT, Thread scopes
Greg Lehey: MALLOC
Guy Helmer: PREEMPTIVE, vfs.read_max
Jon Dama: David Xu's Thrds, Ptmalloc, cpu affinity, sched+hwcacheing
Kris Kennaway: +/-HTT
Robert Watson: Thread scopes, LIBTHR/Linuxthr on 5 and 6?, LOCKING,
HTT, SMP/UP
Thomas Hurst: FreeBSD-current, Don't overload mysql!
Vladimir Chukharev: COMPILEOPTS, TABLETYPES
Xin Li: PROFILE, HTT insignificant

The bad news is that I've not managed to get very far at all lately as
MySQL has been crashing too much to even stop and test stuff
elsewhere.

The good news though, is that the Mysql folks have agreed to setup
tests to profile mysql on identical hardware running FreeBSD and Linux
with an aim to find out exactly where the problem really is. They
reckon they'll spend at least two weeks trying to find out why Linux
is so much faster - if they do this right I'd be surprised if we can't
improve things quite a lot.

Also, it'd be good if any of you who still have an interest in this
could add any ideas or suggestions that may help *them* with their
testing. If so, just get in touch with me asap before they get too
stuck into anything that might prove fruitless.

Here's hoping we can get MySQL running as well on FreeBSD as it ought
to.




I just spent a couple days comparing MySQL 4.1 performance on:

FreeBSD/amd64 5.4-RELEASE (libpthread, system and process scope)
FreeBSD/amd64 6.0-CURRENT (libpthread, libthr, system and process scope)
CentOS/amd64 4.0 (i.e. RHEL4.0)

I couldn't get libthr to work on FreeBSD/amd64 5.4-RELEASE, mysqld 
would immediately coredump and the stacktrace looked like it was 
corrupted (i.e. hundreds of stack frames, all of which were ???).


This was the hardware:

Dell PowerEdge 2850
Dual Xeon 3.6GHz EMT64, HTT disabled
4GB RAM
amr RAID controller w/256MB battery backed cache
5 x 73GB 15K RPM SCSI disks configured as one RAID5 w/64KB stripe

I was seeing the same sort of super-smack numbers that everyone's been 
reporting, i.e. that Linux box was twice as fast as FreeBSD.


It turns out that the problem was the same thing everyone usually 
points the finger at, but no one actually mentioned this time: Linux 
mounts its partitions async by default. I don't have the exact numbers 
in front of me right now, but these were the ballpark figures (I'm not 
going to separate out results for all of the different threading 
libraries for FreeBSD because the deltas weren't huge):


super-smack select-key
5.4-RELEASE ~20,000 queries/second
6.0-CURRENT ~24,000 queries/second
CentOS w/async ~36,000 queries/second
CentOS w/sync ~26,000 queries/second

super-smack update-select
5.4-RELEASE ~4,000 queries/second
6.0-CURRENT ~4,500 queries/second
CentOS w/async ~7,500 queries/second
CentOS w/sync ~750 queries/second

That last CentOS number is not a typo, it was an order of magnitude 
slower. I didn't try other file systems on CentOS, just the default 
ext3. It's possible that reiserfs or xfs might not be as affected by 
switching from async to sync.


So my production server is now happily running mysql 4.1 on 
6.0-CURRENT :).


that explains quite a bit. but why use FreeBSD when you can just turn on 
async on your partitions and get faster queries?

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Uzi]

[...]

super-smack select-key
5.4-RELEASE ~20,000 queries/second
6.0-CURRENT ~24,000 queries/second
CentOS w/async  ~36,000 queries/second
CentOS w/sync   ~26,000 queries/second

super-smack update-select
5.4-RELEASE ~4,000 queries/second
6.0-CURRENT ~4,500 queries/second
CentOS w/async  ~7,500 queries/second
CentOS w/sync   ~750 queries/second

That last CentOS number is not a typo, it was an order of magnitude 
slower.  I didn't try other file systems on CentOS, just the default ext3. 
It's possible that reiserfs or xfs might not be as affected by switching 
from async to sync.


So my production server is now happily running mysql 4.1 on 6.0-CURRENT 
:).


I don't get it.
You get 30% less perfomance, running a non-production release for 
production, and happy about it?


U.





___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"




___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[David Sze]

At 05:15 PM 16/06/2005 +0100, Steve Roome wrote this to All:

Thank you all for your suggestions on this thread, here's a brief
breakdown of most of the ideas from people:

Billy Newsom: COMPILER, DISK, MYSQLVERSION
Daniel Eischen: +/-HTT, Thread scopes
Greg Lehey: MALLOC
Guy Helmer: PREEMPTIVE, vfs.read_max
Jon Dama: David Xu's Thrds, Ptmalloc, cpu affinity, sched+hwcacheing
Kris Kennaway: +/-HTT
Robert Watson: Thread scopes, LIBTHR/Linuxthr on 5 and 6?, LOCKING,
   HTT, SMP/UP
Thomas Hurst: FreeBSD-current, Don't overload mysql!
Vladimir Chukharev: COMPILEOPTS, TABLETYPES
Xin Li: PROFILE, HTT insignificant

The bad news is that I've not managed to get very far at all lately as
MySQL has been crashing too much to even stop and test stuff
elsewhere.

The good news though, is that the Mysql folks have agreed to setup
tests to profile mysql on identical hardware running FreeBSD and Linux
with an aim to find out exactly where the problem really is. They
reckon they'll spend at least two weeks trying to find out why Linux
is so much faster - if they do this right I'd be surprised if we can't
improve things quite a lot.

Also, it'd be good if any of you who still have an interest in this
could add any ideas or suggestions that may help *them* with their
testing. If so, just get in touch with me asap before they get too
stuck into anything that might prove fruitless.

Here's hoping we can get MySQL running as well on FreeBSD as it ought
to.



I just spent a couple days comparing MySQL 4.1 performance on:

FreeBSD/amd64 5.4-RELEASE (libpthread, system and process scope)
FreeBSD/amd64 6.0-CURRENT (libpthread, libthr, system and process 
scope)

CentOS/amd64 4.0 (i.e. RHEL4.0)

I couldn't get libthr to work on FreeBSD/amd64 5.4-RELEASE, mysqld would 
immediately coredump and the stacktrace looked like it was corrupted (i.e. 
hundreds of stack frames, all of which were ???).


This was the hardware:

Dell PowerEdge 2850
Dual Xeon 3.6GHz EMT64, HTT disabled
4GB RAM
amr RAID controller w/256MB battery backed cache
5 x 73GB 15K RPM SCSI disks configured as one RAID5 w/64KB stripe

I was seeing the same sort of super-smack numbers that everyone's been 
reporting, i.e. that Linux box was twice as fast as FreeBSD.


It turns out that the problem was the same thing everyone usually points 
the finger at, but no one actually mentioned this time:  Linux mounts its 
partitions async by default.  I don't have the exact numbers in front of me 
right now, but these were the ballpark figures (I'm not going to separate 
out results for all of the different threading libraries for FreeBSD 
because the deltas weren't huge):


super-smack select-key
5.4-RELEASE ~20,000 queries/second
6.0-CURRENT ~24,000 queries/second
CentOS w/async  ~36,000 queries/second
CentOS w/sync   ~26,000 queries/second

super-smack update-select
5.4-RELEASE ~4,000 queries/second
6.0-CURRENT ~4,500 queries/second
CentOS w/async  ~7,500 queries/second
CentOS w/sync   ~750 queries/second

That last CentOS number is not a typo, it was an order of magnitude 
slower.  I didn't try other file systems on CentOS, just the default 
ext3.  It's possible that reiserfs or xfs might not be as affected by 
switching from async to sync.


So my production server is now happily running mysql 4.1 on 6.0-CURRENT :).



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Kernel module/IPC with userland: create and write to FIFO

[Daniel O'Connor]

On Fri, 17 Jun 2005 23:47, Hannes Mayer wrote:
> > If you read and write to it, it acts like a FIFO.
>
> Thanks for your reply! :-)
>
> Well, the reason why I want to use a true FIFO is, that data is
> sampled i.e. every second and I want to write it to disk in userspace
> only every minute or so. So if I add a ".d_ioctl" to "struct cdevsw"

I wasn't suggesting an ioctl(), just read().

> for the device node, I have to make a function in the kernel module
> for handling the userspace read request and I have to cache the
> sampled data in the kernel module. I want the module to be flexible,

The read() function is really quite simple, as for the caching - that can be 
done in userland.

> so if I don't sample at a fixed frequency (i.e. event counting) I
> don't know how much data is coming in in a certain time interval and
> with a FIFO  I don't have to care about the data-cache size.

I would suggest that you buffer it in userland.

Ie have a small buffer in the kernel and have a userland process that reads 
from the kernel as soon as data is ready and stores it in memory. 

Doing it this way makes it much simpler to modify your write strategy as you 
need to.

It doesn't matter what the variability of the data rate is if you use 
read/write since the userland app will spend 99% of it's time waiting in 
select() for the kernel to tell it when new data is available.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C


pgpYidpcXCJ1q.pgp
Description: PGP signature

Re: Kernel module/IPC with userland: create and write to FIFO

[Hannes Mayer]

G'Day Daniel!

On 6/17/05, Daniel O'Connor <[EMAIL PROTECTED]> wrote:
> On Fri, 17 Jun 2005 21:36, Hannes Mayer wrote:
> > To cut a long story short, how can I open a FIFO in kernel space and
> > write to it, so I can open and read from it in userspace ?
> 
> Why don't you create a device node?
> 
> If you read and write to it, it acts like a FIFO.

Thanks for your reply! :-)

Well, the reason why I want to use a true FIFO is, that data is
sampled i.e. every second and I want to write it to disk in userspace
only every minute or so. So if I add a ".d_ioctl" to "struct cdevsw"
for the device node, I have to make a function in the kernel module
for handling the userspace read request and I have to cache the
sampled data in the kernel module. I want the module to be flexible,
so if I don't sample at a fixed frequency (i.e. event counting) I
don't know how much data is coming in in a certain time interval and
with a FIFO  I don't have to care about the data-cache size.

Thanks again & best regards,
Hannes.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Robert Watson]

On Thu, 16 Jun 2005, Steve Roome wrote:

The good news though, is that the Mysql folks have agreed to setup tests 
to profile mysql on identical hardware running FreeBSD and Linux with an 
aim to find out exactly where the problem really is. They reckon they'll 
spend at least two weeks trying to find out why Linux is so much faster 
- if they do this right I'd be surprised if we can't improve things 
quite a lot.


Also, it'd be good if any of you who still have an interest in this 
could add any ideas or suggestions that may help *them* with their 
testing. If so, just get in touch with me asap before they get too stuck 
into anything that might prove fruitless.


Here's hoping we can get MySQL running as well on FreeBSD as it ought 
to.


Please let me know if there's any support for this activity I can provide. 
I spent a fair amount of time identifying bottlenecks for MySQL in the 5.x 
cycle, and I know David Xu ([EMAIL PROTECTED]) has also spent quite a 
bit of time looking at the threading side, resulting in a lot of his work 
on libthr in 6.x.  It would probably be a good idea to (a) move further 
discussion to [EMAIL PROTECTED], and (b) make sure that the 
performance work is starting with a recent 6.x baseline (with debugging 
turned off).


thanks for the time you've been putting into this!

Robert N M Watson
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Steve Roome]

Thank you all for your suggestions on this thread, here's a brief
breakdown of most of the ideas from people:

Billy Newsom: COMPILER, DISK, MYSQLVERSION
Daniel Eischen: +/-HTT, Thread scopes
Greg Lehey: MALLOC
Guy Helmer: PREEMPTIVE, vfs.read_max
Jon Dama: David Xu's Thrds, Ptmalloc, cpu affinity, sched+hwcacheing
Kris Kennaway: +/-HTT
Robert Watson: Thread scopes, LIBTHR/Linuxthr on 5 and 6?, LOCKING,
   HTT, SMP/UP
Thomas Hurst: FreeBSD-current, Don't overload mysql!
Vladimir Chukharev: COMPILEOPTS, TABLETYPES
Xin Li: PROFILE, HTT insignificant

The bad news is that I've not managed to get very far at all lately as
MySQL has been crashing too much to even stop and test stuff
elsewhere.

The good news though, is that the Mysql folks have agreed to setup
tests to profile mysql on identical hardware running FreeBSD and Linux
with an aim to find out exactly where the problem really is. They
reckon they'll spend at least two weeks trying to find out why Linux
is so much faster - if they do this right I'd be surprised if we can't
improve things quite a lot.

Also, it'd be good if any of you who still have an interest in this
could add any ideas or suggestions that may help *them* with their
testing. If so, just get in touch with me asap before they get too
stuck into anything that might prove fruitless.

Here's hoping we can get MySQL running as well on FreeBSD as it ought
to.

Thanks again everyone,

Steve Roome
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

mount floppy - Input/output error

[Горсткин Илья]

Hi!

Such problem!

# uname -rs
FreeBSD 5.4-RELEASE-p1

# mount -t msdosfs /dev/fd0 /mnt/flp 
msdosfs: /dev/fd0: Input/output error 

# fdformat -f 1440 /dev/fd0 
Format 1440K floppy `/dev/fd0'? (y/n): y 
Processing fdformat: ioctl(FD_FORM): Input/output error 

# fdcontrol -v /dev/fd0
/dev/fd0: 1.44M drive (3.5" high-density)

#cat /etc/fstab |grep fd 
/dev/fd0/mnt/flpmsdos   rw,noauto 0   0 

# ls /dev |grep fd 
fd 
fd0 

# cat /var/run/dmesg.boot |grep fd 
fdc0:  port 0x3f7,0x3f0-0x3f5 irq 6 on
acpi0 
fdc0: cannot reserve DMA request line 
fd0: <1440-KB 3.5" drive> on fdc0 drive 0

Help to solve a problem!
thanks

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Kernel module/IPC with userland: create and write to FIFO

[Daniel O'Connor]

On Fri, 17 Jun 2005 21:36, Hannes Mayer wrote:
> To cut a long story short, how can I open a FIFO in kernel space and
> write to it, so I can open and read from it in userspace ?

Why don't you create a device node?

If you read and write to it, it acts like a FIFO.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C


pgpZvHUA95Bdr.pgp
Description: PGP signature

Re: rebooting problem

[GMane]

Hi Cian,

"Cian Hughes" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Do you also have a hanging problem if you shutdown with `shutdown -p 
> now`?

  No, the problem it's only with the reboot command.

> Are you using ACPI?
> Have you ensured you are using the latest BIOS for you system?

   I turned off the ACPI from the BIOS. (but from the dmesg it seems on)

> When did you last compile your kernel?

when I upgraded the system to the Freebsd-5.4

> Could you give some specifics about architecture, output of dmesg and 
> your hardware setup.

The dmesg output:

Copyright (c) 1992-2005 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.4-STABLE #5: Mon May 16 12:21:11 CEST 2005

Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Celeron(R) CPU 2.40GHz (2394.01-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0xf41  Stepping = 1
  
Features=0xbfebfbff
real memory  = 268419072 (255 MB)
avail memory = 253014016 (241 MB)
npx0:  on motherboard
npx0: INT 16 interface
acpi0:  on motherboard
acpi0: Power Button (fixed)
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0
cpu0:  on acpi0
acpi_throttle0:  on cpu0
acpi_button0:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
agp0:  mem 0xe800-0xebff at device 0.0 
on pci0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
pci1:  at device 0.0 (no driver attached)
isab0:  at device 2.0 on pci0
isa0:  on isab0
atapci0:  port 
0xa400-0xa40f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 irq 11 at device 2.5 on 
pci0
ata0: channel #0 on atapci0
ata1: channel #1 on atapci0
ohci0:  mem 0xe700-0xe7000fff irq 12 at device 
3.0 on pci0
usb0: OHCI version 1.0, legacy support
usb0:  on ohci0
usb0: USB revision 1.0
uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 3 ports with 3 removable, self powered
ohci1:  mem 0xe680-0xe6800fff irq 3 at device 
3.1 on pci0
usb1: OHCI version 1.0, legacy support
usb1:  on ohci1
usb1: USB revision 1.0
uhub1: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 3 ports with 3 removable, self powered
pci0:  at device 3.3 (no driver attached)
sis0:  port 0x8800-0x88ff mem 0xe580-0xe5800fff at 
device 4.0 on pci0
miibus0:  on sis0
rlphy0:  on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
sis0: Ethernet address: 00:11:2f:99:20:2f
xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0x8400-0x847f mem 
0xe500-0xe57f irq 10 at device 16.0 on pci0
miibus1:  on xl0
ukphy0:  on miibus1
ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xl0: Ethernet address: 00:0a:5e:50:0b:46
ppc0:  port 0x778-0x77b,0x378-0x37f irq 7 drq 3 
on acpi0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/16 bytes threshold
ppbus0:  on ppc0
plip0:  on ppbus0
lpt0:  on ppbus0
lpt0: Interrupt-driven port
ppi0:  on ppbus0
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on 
acpi0
sio0: type 16550A
atkbdc0:  port 0x64,0x60 irq 1 on acpi0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
orm0:  at iomem 0xd-0xd07ff,0xc-0xccfff on isa0
pmtimer0 on isa0
fdc0: cannot allocate I/O port (6 ports)
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
Timecounter "TSC" frequency 2394010647 Hz quality 800
Timecounters tick every 10.000 msec
ad0: 38166MB  [77545/16/63] at ata0-master UDMA100
acd0: CDROM  at ata1-master PIO4
Mounting root from ufs:/dev/ad0s1a
ipfw2 initialized, divert disabled, rule-based forwarding disabled, default 
to deny, logging disabled

Thank You,
Regards, Ricki

>
> Regards, Cian
>
> On 17 Meith 2005, at 10:58, GMane wrote:
>
>> Hi,
>>
>> When I try to reboot my machine it hangs on and I have to do it  manually
>> pressing the reset button.
>>
>> Did anyone have the same problem?
>> Do You think that is an hardware problem?
>>
>> I thank you all!
>>
>> Ricki
>>
>>
>>
>> ___
>> freebsd-stable@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable- 
>> [EMAIL PROTECTED]"
>>
>
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> 



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Kernel module/IPC with userland: create and write to FIFO

[Hannes Mayer]

Hi all!

I've modified a standard driver and now I'd like to create a FIFO in
it to communicate / send data to a userland process.

Opening, reading and writing to a FIFO in userland is easy, but I have
no clue how to do this in kernel space. Googling and looking to the
kernel source didn't help.
The only thing I found is "kern_mkfifo" and int mkfifo(struct thread,
struct mkfifo_args);, but no example on how to use them (if that's the
right approach anyway).

To cut a long story short, how can I open a FIFO in kernel space and
write to it, so I can open and read from it in userspace ?

Thanks in advance for any hints!
Best regards,
Hannes.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: rebooting problem

[Cian Hughes]

Do you also have a hanging problem if you shutdown with `shutdown -p  
now`?

Are you using ACPI?
Have you ensured you are using the latest BIOS for you system?
When did you last compile your kernel?
Could you give some specifics about architecture, output of dmesg and  
your hardware setup.


Regards, Cian

On 17 Meith 2005, at 10:58, GMane wrote:


Hi,

When I try to reboot my machine it hangs on and I have to do it  
manually

pressing the reset button.

Did anyone have the same problem?
Do You think that is an hardware problem?

I thank you all!

Ricki



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable- 
[EMAIL PROTECTED]"




___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

rebooting problem

[GMane]

Hi,

When I try to reboot my machine it hangs on and I have to do it manually 
pressing the reset button.

Did anyone have the same problem?
Do You think that is an hardware problem?

I thank you all!

Ricki 



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: kern/80642: [patch] IPFW small patch - new RULE OPTION

[Andrey V. Elsukov]

Robert Watson wrote:
 > This patch breaks the ABI by inserting a new type into an implicitly
 > numbered enumeration, renumbering all entries later in the enum.
 > O_BOUND, if added, should be appended to the end, and/or we should
 > number  the operations explicitly.

Ok. I have corrected this.
* ipfw_bound.diff - the patch with smallest changes, with only bound option.
* ipfw_bound2.diff - bound and check-bound option.

Examples:

We can limit incoming traffic (internet is external interface):
# ipfw add allow ip from any to 10.0.0.20 in recv internet bound 10MB
# ipfw add deny ip from any to 10.0.0.0/24 in recv internet

We can use traffic shaper after excess of a limit:
# ipfw add allow ip from any to 10.0.0.20 in recv internet bound 10MB
# ipfw add pipe 1 ip from any to 10.0.0.20 in recv internet
# ipfw pipe 1 config bw 5Kbit/s queue 10Kbytes

We can block any access after limit excess:
# ipfw add 100 allow ip from 10.0.0.20 to any out xmit internet \
check-bound 200
# ipfw add 200 allow ip from any to 10.0.0.20 in recv internet bound \ 10MB
# ipfw add 300 deny ip from any to any

More details you can read on http://butcher.heavennet.ru/
--
WBR, Andrey V. Elsukov
--- sbin/ipfw/ipfw2.c   Tue Jun  7 18:11:17 2005
+++ sbin/ipfw/ipfw2.c   Fri Jun 17 13:09:43 2005
@@ -277,6 +277,7 @@
TOK_SRCIP6,
 
TOK_IPV4,
+   TOK_BOUND,
 };
 
 struct _s_x dummynet_params[] = {
@@ -403,6 +404,7 @@
{ "dst-ip6",TOK_DSTIP6},
{ "src-ipv6",   TOK_SRCIP6},
{ "src-ip6",TOK_SRCIP6},
+   { "bound",  TOK_BOUND},
{ "//", TOK_COMMENT },
 
{ "not",TOK_NOT },  /* pseudo option */
@@ -1858,6 +1860,10 @@
print_ext6hdr( (ipfw_insn *) cmd );
break;
 
+   case O_BOUND:
+   printf(" bound %u", ((ipfw_insn_u64 
*)cmd)->bound);
+   break;
+
default:
printf(" [opcode %d len %d]",
cmd->opcode, cmd->len);
@@ -2515,7 +2521,7 @@
 "  icmp6types LIST | ext6hdr LIST | flow-id N[,N] |\n"
 "  mac ... | mac-type LIST | proto LIST | {recv|xmit|via} {IF|IPADDR} |\n"
 "  setup | {tcpack|tcpseq|tcpwin} NN | tcpflags SPEC | tcpoptions SPEC |\n"
-"  tcpdatalen LIST | verrevpath | versrcreach | antispoof\n"
+"  tcpdatalen LIST | verrevpath | versrcreach | antispoof | bound VALUE\n"
 );
 exit(0);
 }
@@ -3683,6 +3689,7 @@
int i;
 
int open_par = 0;   /* open parenthesis ( */
+   int have_bound = 0;
 
/* proto is here because it is used to fetch ports */
u_char proto = IPPROTO_IP;  /* default protocol */
@@ -4492,6 +4499,33 @@
fill_comment(cmd, ac, av);
av += ac;
ac = 0;
+   break;
+
+   case TOK_BOUND:
+   NEED1("bound requires numeric value");
+   if (have_bound)
+   errx(EX_USAGE, "only one of bound is allowed");
+   if (open_par)
+   errx(EX_USAGE, "bound cannot be part "
+   "of an or block"); 
+   if (cmd->len & F_NOT)
+   errx(EX_USAGE, 
+   "\"not\" not allowed with bound option"); 
+   {
+   char *end = NULL;
+   uint64_t bound = strtoull(*av, &end, 0);
+   if (bound)
+   switch (*end){
+   case 'G': bound *= 1024;
+   case 'M': bound *= 1024;
+   case 'K': bound *= 1024;
+   };
+   cmd->opcode = O_BOUND;
+   ((ipfw_insn_u64 *)cmd)->bound = bound;
+   cmd->len = F_INSN_SIZE(ipfw_insn_u64) & 
F_LEN_MASK;
+   have_bound = 1;
+   ac--; av++;
+   } 
break;
 
default:
--- sys/netinet/ip_fw.h Fri Jun  3 05:10:28 2005
+++ sys/netinet/ip_fw.h Fri Jun 17 11:30:30 2005
@@ -154,6 +154,7 @@
O_NGTEE,/* copy to ng_ipfw  */
 
O_IP4,
+   O_BOUND,/* u64 = bound in bytes */
 
O_LAST_OPCODE   /* not an opcode!   */
 };
@@ -228,6 +229,14 @@
ipfw_insn o;
u_int32_t d[1]; /* one or more */
 } ipfw_insn_u32;
+
+/*
+ * This is used to store 64-bit bound value.
+ */
+typedef struct _ipfw_insn_u64 {
+   ipfw_insn o;
+   u_int64_t bound

Problem with C4B on FreeBSD-Stable

[Cian Hughes]

I get this error on boot:
CAPI subsystem startup: kcapimgr capidev
avmaic avmaic0:  port 0xec80-0xec9f,0xecc0-0xecff mem  
0xfdfffc00-0xfdfffc3f irq 10 at device 8.0 on pci1

avmaic0: "AVMB1-1" successfully attached as CAPI controller 1
kcapimgr: E kcapi_reset_ctlr: ERROR: Root permission required to  
reset controller 1
Error in download operation for board "AVMB1-1", number 1:  
Insufficient rights, must have root privileges

/etc/rc: WARNING: Download command for avmaic failed.

if you have any suggestions I would be most obliged.

also if I type this from a command line:
oppy# avmaicctl -q -f /etc/avmaic.cfg
Error in download operation for board "AVMB1-1", number 1:  
Insufficient rights, must have root privileges
(and on console: kcapimgr: E kcapi_reset_ctlr: ERROR: Root permission  
required to reset controller 1)


Regards,
   Cian Hughes
--
E  [EMAIL PROTECTED]
NIC Handle CIAN-6BONE
M +353-86-8465317
H +353-1-4991205
F +353-1-4900248

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"