OSR6 with MP1

Up until OSR6, I was still using the Xenix 386 sort, which runs
approximately 3 x faster than the Openserver sort. It doesn't run at
all on OSR6 though, and immediately fails with:

sort: allocation error before sort

I've tried running it under truss, but I don't see anything obviously
wrong. Would someone more knowledgable care to look at the truss
output and give their opinion? It can be seen here:

http://tenzing.org/xenix-sort

"Roger Cornelius" <rac@tenzing.org> wrote in message
news:1126140401.425597.163360@g47g2000cwa.googlegr oups.com...
> OSR6 with MP1
>
> Up until OSR6, I was still using the Xenix 386 sort, which runs
> approximately 3 x faster than the Openserver sort. It doesn't run at
> all on OSR6 though, and immediately fails with:
>
> sort: allocation error before sort
>
> I've tried running it under truss, but I don't see anything obviously
> wrong. Would someone more knowledgable care to look at the truss
> output and give their opinion? It can be seen here:
>
> http://tenzing.org/xenix-sort
>

There are still problems with xemul on OSR 6.0.0 w/MP1.
Perhaps you've stumbled upon one of them. Could you post
the sort.x386 binary on your webpage, along with the data file
you're trying to sort and the exact command line you're
using to invoke it? I would be happy to try it out using
a newer version of xemul. (Or does the error occur
simply by entering "sort.x386" at the command line with
no arguments?)

Please note that you can create a simple trace directly
from xemul (instead of using truss), and there's also
an option to more closely emulate OSR5 behavior.
See man xemul.

Bob

Roger Cornelius wrote:

> OSR6 with MP1
>
> Up until OSR6, I was still using the Xenix 386 sort, which runs
> approximately 3 x faster than the Openserver sort. It doesn't run at
> all on OSR6 though, and immediately fails with:
>
> sort: allocation error before sort
>
> I've tried running it under truss, but I don't see anything obviously
> wrong. Would someone more knowledgable care to look at the truss
> output and give their opinion? It can be seen here:
>
> http://tenzing.org/xenix-sort

The call right before failure, `sysi86(SI86DSCR)', is doing something to
the process's memory map. Immediately thereafter, it fails with a
memory-related error message. It appears that the kernel or `xemul'
emulation layer isn't emulating this particular call cleanly enough.

Stepping back: OSR5's slow `sort` always irked me. It's caused by the
implementation of internationalized collation sequences. This is code
in libc which was imported into OSR5 from UnixWare 2 (this was long
before SCO bought UnixWare; they bought a license to the SVR4/UW2
compiler and libc). The same code lived on into UW7 and beyond, but the
performance issues were long since fixed. `sort` on UW7 is performant.

OSR6 uses a merged libc for OSR5/OSR6 binaries, but apparently this part
is more OSR5 than UW7.

You might try grabbing a UW7 (714 would be best) `sort` binary to see if
it performs any better. It would run against the UW7-specific libc in
OSR6, which hopefully has the faster collation code.

I did test this on OSR506; a randomly chosen UW7 `sort` binary runs some
simple tests about 2.5x as fast as the native one.

>Bela<

Bela Lubkin wrote:
> Roger Cornelius wrote:
>
> > OSR6 with MP1
> >
> > Up until OSR6, I was still using the Xenix 386 sort, which runs
> > approximately 3 x faster than the Openserver sort. It doesn't run at
> > all on OSR6 though, and immediately fails with:
> >
> > sort: allocation error before sort
> >
> > I've tried running it under truss, but I don't see anything obviously
> > wrong. Would someone more knowledgable care to look at the truss
> > output and give their opinion? It can be seen here:
> >
> > http://tenzing.org/xenix-sort
>
> The call right before failure, `sysi86(SI86DSCR)', is doing something to
> the process's memory map. Immediately thereafter, it fails with a
> memory-related error message. It appears that the kernel or `xemul'
> emulation layer isn't emulating this particular call cleanly enough.

The call to sysi86() returned 0 and sys/fault.h says FLTPAGE is
recoverable, so I wasn't sure if that was notable or not. There were
many previous FLTPAGEs prior to that one.

> Stepping back: OSR5's slow `sort` always irked me. It's caused by the
> implementation of internationalized collation sequences. This is code
> in libc which was imported into OSR5 from UnixWare 2 (this was long
> before SCO bought UnixWare; they bought a license to the SVR4/UW2
> compiler and libc). The same code lived on into UW7 and beyond, but the
> performance issues were long since fixed. `sort` on UW7 is performant.

Do a google groups search on "slow sco unix sort" to see a thread on
this from 1991.

> OSR6 uses a merged libc for OSR5/OSR6 binaries, but apparently this part
> is more OSR5 than UW7.
>
> You might try grabbing a UW7 (714 would be best) `sort` binary to see if
> it performs any better. It would run against the UW7-specific libc in
> OSR6, which hopefully has the faster collation code.
>
> I did test this on OSR506; a randomly chosen UW7 `sort` binary runs some
> simple tests about 2.5x as fast as the native one.

I don't have access to a UW7 box so maybe someone will volunteer to
send me one. It would be interesting to get the Xenix sort working and
compare against UW and OSR6.

Bob Bailin wrote:
> "Roger Cornelius" <rac@tenzing.org> wrote in message
> news:1126140401.425597.163360@g47g2000cwa.googlegr oups.com...
> > OSR6 with MP1
> >
> > Up until OSR6, I was still using the Xenix 386 sort, which runs
> > approximately 3 x faster than the Openserver sort. It doesn't run at
> > all on OSR6 though, and immediately fails with:
> >
> > sort: allocation error before sort
> >
> > I've tried running it under truss, but I don't see anything obviously
> > wrong. Would someone more knowledgable care to look at the truss
> > output and give their opinion? It can be seen here:
> >
> > http://tenzing.org/xenix-sort
> >
>
> There are still problems with xemul on OSR 6.0.0 w/MP1.
> Perhaps you've stumbled upon one of them. Could you post
> the sort.x386 binary on your webpage, along with the data file
> you're trying to sort and the exact command line you're
> using to invoke it? I would be happy to try it out using
> a newer version of xemul. (Or does the error occur
> simply by entering "sort.x386" at the command line with
> no arguments?)

The error occurs whether or not I supply arguments to sort. To produce
the truss.out file, I called it with no arguments.

> Please note that you can create a simple trace directly
> from xemul (instead of using truss), and there's also
> an option to more closely emulate OSR5 behavior.
> See man xemul.

Setting XEMUL_OSR5 has no effect but I'm unable to convince xemul to
produce a trace file as described in the man page either. Does
XEMUL_TRACE require a particular value? The man page is unclear.

"Roger Cornelius" <rac@tenzing.org> wrote in message
news:1126184650.675059.174090@g49g2000cwa.googlegr oups.com...
> Bob Bailin wrote:
>> "Roger Cornelius" <rac@tenzing.org> wrote in message
>> news:1126140401.425597.163360@g47g2000cwa.googlegr oups.com...
>> > OSR6 with MP1
>> >
>> > Up until OSR6, I was still using the Xenix 386 sort, which runs
>> > approximately 3 x faster than the Openserver sort. It doesn't run at
>> > all on OSR6 though, and immediately fails with:
>> >
>> > sort: allocation error before sort
>> >
>> > I've tried running it under truss, but I don't see anything obviously
>> > wrong. Would someone more knowledgable care to look at the truss
>> > output and give their opinion? It can be seen here:
>> >
>> > http://tenzing.org/xenix-sort
>> >
>>
>> There are still problems with xemul on OSR 6.0.0 w/MP1.
>> Perhaps you've stumbled upon one of them. Could you post
>> the sort.x386 binary on your webpage, along with the data file
>> you're trying to sort and the exact command line you're
>> using to invoke it? I would be happy to try it out using
>> a newer version of xemul. (Or does the error occur
>> simply by entering "sort.x386" at the command line with
>> no arguments?)
>
> The error occurs whether or not I supply arguments to sort. To produce
> the truss.out file, I called it with no arguments.
>
>> Please note that you can create a simple trace directly
>> from xemul (instead of using truss), and there's also
>> an option to more closely emulate OSR5 behavior.
>> See man xemul.
>
> Setting XEMUL_OSR5 has no effect but I'm unable to convince xemul to
> produce a trace file as described in the man page either. Does
> XEMUL_TRACE require a particular value? The man page is unclear.
>

Use:

XEMUL_TRACE=1 (simply setting it any value, e.g. 'TRUE', doesn't work)
export XEMUL_TRACE

The trace file will appear in the current directory, not /tmp as implied by
the man page.

xemul trace output (xtrace.21736):
close(3) err #9 (EBADF)
close(4) = 0
close(5) err #9 (EBADF)
[close(6) ... close(17)]
close(18) err #9 (EBADF)
ulimit(3, 0) err #22 (EINVAL)
brk(0xfffffffc) err #22 (EINVAL)
write(2, 0x188067c, 6) = 6
write(2, 0x188008c, 28) = 28
write(2, 0x188008a, 0) err #14 (EFAULT) [= 0 if XEMUL_OSR5=1 is
set]
write(2, 0x1880684, 1) = 1
close(0) = 0
close(1) = 0
close(2) = 0
exit(1)

Not very useful. The error is being trapped and handled by
the binary itself.

Is the -y option for memory allocation the same in both Xenix & OSR?

Bob

Bob Bailin wrote:
> "Roger Cornelius" <rac@tenzing.org> wrote in message
> news:1126184650.675059.174090@g49g2000cwa.googlegr oups.com...
> > Bob Bailin wrote:
> >> "Roger Cornelius" <rac@tenzing.org> wrote in message
> >> news:1126140401.425597.163360@g47g2000cwa.googlegr oups.com...
> >> > OSR6 with MP1
> >> >
> >> > Up until OSR6, I was still using the Xenix 386 sort, which runs
> >> > approximately 3 x faster than the Openserver sort. It doesn't run at
> >> > all on OSR6 though, and immediately fails with:
> >> >
> >> > sort: allocation error before sort
> >> >
> >> > I've tried running it under truss, but I don't see anything obviously
> >> > wrong. Would someone more knowledgable care to look at the truss
> >> > output and give their opinion? It can be seen here:
> >> >
> >> > http://tenzing.org/xenix-sort
> >> >
> >>
> >> There are still problems with xemul on OSR 6.0.0 w/MP1.
> >> Perhaps you've stumbled upon one of them. Could you post
> >> the sort.x386 binary on your webpage, along with the data file
> >> you're trying to sort and the exact command line you're
> >> using to invoke it? I would be happy to try it out using
> >> a newer version of xemul. (Or does the error occur
> >> simply by entering "sort.x386" at the command line with
> >> no arguments?)
> >
> > The error occurs whether or not I supply arguments to sort. To produce
> > the truss.out file, I called it with no arguments.
> >
> >> Please note that you can create a simple trace directly
> >> from xemul (instead of using truss), and there's also
> >> an option to more closely emulate OSR5 behavior.
> >> See man xemul.
> >
> > Setting XEMUL_OSR5 has no effect but I'm unable to convince xemul to
> > produce a trace file as described in the man page either. Does
> > XEMUL_TRACE require a particular value? The man page is unclear.
> >
>
> Use:
>
> XEMUL_TRACE=1 (simply setting it any value, e.g. 'TRUE', doesn't work)
> export XEMUL_TRACE

Kind of an important detail to leave out of the man page.

> The trace file will appear in the current directory, not /tmp as implied by
> the man page.
>
> xemul trace output (xtrace.21736):
> close(3) err #9 (EBADF)
> close(4) = 0
> close(5) err #9 (EBADF)
> [close(6) ... close(17)]
> close(18) err #9 (EBADF)
> ulimit(3, 0) err #22 (EINVAL)
> brk(0xfffffffc) err #22 (EINVAL)
> write(2, 0x188067c, 6) = 6
> write(2, 0x188008c, 28) = 28
> write(2, 0x188008a, 0) err #14 (EFAULT) [= 0 if XEMUL_OSR5=1 is
> set]
> write(2, 0x1880684, 1) = 1
> close(0) = 0
> close(1) = 0
> close(2) = 0
> exit(1)
>
> Not very useful. The error is being trapped and handled by
> the binary itself.
>
> Is the -y option for memory allocation the same in both Xenix & OSR?

The manual pages describe -y similarly for both but I have no idea how
they operate internally.

----- Original Message -----
From: "Roger Cornelius" <rac@tenzing.org>
Newsgroups: comp.unix.sco.misc
To: <distro@jpr.com>
Sent: Wednesday, September 07, 2005 8:46 PM
Subject: xenix 386 sort fails on OSR6


> OSR6 with MP1
>
> Up until OSR6, I was still using the Xenix 386 sort, which runs
> approximately 3 x faster than the Openserver sort. It doesn't run at

nice little trick to know, thanks.

how does gnu sort fare?

Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

Brian K. White wrote:
>
> > OSR6 with MP1
> >
> > Up until OSR6, I was still using the Xenix 386 sort, which runs
> > approximately 3 x faster than the Openserver sort. It doesn't run at
>
> nice little trick to know, thanks.
>
> how does gnu sort fare?

Not very well. Below are the results of 5 iterations each of various
sorts running on OSR507 sorting a 15mb file consisting of 100
concatenated copies of /etc/termcap. The gnu sort is the one included
with the SCO GNU development tools and performed the worst on this
data. The unixware sort is right up there with the xenix 386 one and
has the advantage of hopefully several years worth of bug fixes.

** /bin/sort

real 0m4.36s
user 0m3.49s
sys 0m0.25s

real 0m5.72s
user 0m3.51s
sys 0m0.32s

real 0m5.63s
user 0m3.42s
sys 0m0.34s

real 0m4.93s
user 0m3.50s
sys 0m0.31s

real 0m5.67s
user 0m3.52s
sys 0m0.28s

** /usr/gnu/bin/sort

real 0m5.89s
user 0m5.20s
sys 0m0.25s

real 0m5.88s
user 0m5.17s
sys 0m0.26s

real 0m5.88s
user 0m5.34s
sys 0m0.11s

real 0m5.90s
user 0m5.30s
sys 0m0.16s

real 0m5.90s
user 0m5.22s
sys 0m0.23s

** /u/bin/sort.xenix-386

real 0m1.35s
user 0m0.67s
sys 0m0.32s

real 0m2.95s
user 0m0.71s
sys 0m0.26s

real 0m2.95s
user 0m0.73s
sys 0m0.24s

real 0m2.95s
user 0m0.75s
sys 0m0.22s

real 0m2.53s
user 0m0.73s
sys 0m0.24s

** /u/bin/sort.unixware

real 0m2.84s
user 0m0.60s
sys 0m0.26s

real 0m2.84s
user 0m0.61s
sys 0m0.25s

real 0m2.84s
user 0m0.57s
sys 0m0.29s

real 0m2.29s
user 0m0.54s
sys 0m0.32s

real 0m1.10s
user 0m0.56s
sys 0m0.30s

On Fri, Sep 09, 2005, Roger Cornelius wrote:
>Brian K. White wrote:
>>
>> > OSR6 with MP1
>> >
>> > Up until OSR6, I was still using the Xenix 386 sort, which runs
>> > approximately 3 x faster than the Openserver sort. It doesn't run at
>>
>> nice little trick to know, thanks.
>>
>> how does gnu sort fare?
>
>Not very well. Below are the results of 5 iterations each of various
>sorts running on OSR507 sorting a 15mb file consisting of 100
>concatenated copies of /etc/termcap. The gnu sort is the one included
>with the SCO GNU development tools and performed the worst on this
>data. The unixware sort is right up there with the xenix 386 one and
>has the advantage of hopefully several years worth of bug fixes.

One factor is probably that I doubt that the xenix sort handles anything
but standard ASCII text while all the others sort appropriately based on
the setting of the LANG environment variable. The first time I became
aware of this was when running ``make test'' on one of the gnu packages
which failed on the sort until I set LANG=C to make sort behave in what
many system administrators would consider a normal manner.

Bill
--
INTERNET: bill@Celestial.COM Bill Campbell; Celestial Systems, Inc.
UUCP: camco!bill PO Box 820; 6641 E. Mercer Way
FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
URL: http://www.celestial.com/

There is no distinctly native American criminal class save Congress
-- Mark Twain