Re: USB UHCI speed issue ?

2002-01-20 Thread Josef Karthauser

On Sat, Jan 19, 2002 at 05:39:56PM -0800, Duane H. Hesser wrote:
> 
> I can confirm the problem, and point you to a message in the "current"
> archives (Dec 15) which contains a simple 3 or 4 line patch to uhui.c.
> The message, authored by Andrew Gordon, may be found at
> 
> 
>http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=775757+780830+/usr/local/www/db/text/2001/freebsd-current/20011216.freebsd-curren
> t

Hmm. :) Looking at the NetBSD code, they made a major commit to fix the
same issue:

uhci.c revision 1.123
date: 2000/08/13 16:18:09;  author: augustss;  state: Exp;  lines: +136 -31
Implement what in Intel-speech is known as "bandwidth reclamation".
It means that we continously poll USB devices that have a pending transfer
instead of polling just once every ms.  This speeds up some transfers
at the expense of using more PCI bandwidth.

I'm looking at what is necessary to port that change over.

Joe



msg31044/pgp0.pgp
Description: PGP signature


Re: ftpd patch that saves me a lot of hassle

2002-01-20 Thread Alfred Perlstein

* Aaron Smith <[EMAIL PROTECTED]> [020119 12:29] wrote:
> I got sick of (presumably) warez people probing my anonymous ftp site and
> dropping all kinds of hard-to-delete trash in incoming, so I patched my
> ftpd to only allow directories to start with alphanumerics. There's
> probably a better solution, but this works for me so I figure'd I'd share.
> 
> Combining this with a umask that doesn't allow reading uploaded files keeps
> things reasonably well in hand.

This is cool, would be cooler if it was a regex or something to validate
the names passed in via a command line, also could be used to protect
against evil filenames. :)

> 
> --Aaron
> 
> 
> Index: ftpd.c
> ===
> RCS file: /usr/cvs/src/libexec/ftpd/ftpd.c,v
> retrieving revision 1.62.2.15
> diff -u -r1.62.2.15 ftpd.c
> --- ftpd.c2001/12/18 18:35:55 1.62.2.15
> +++ ftpd.c2002/01/19 09:47:42
> @@ -2216,6 +2216,12 @@
>  {
>  
>   LOGCMD("mkdir", name);
> +
> + if (!isalnum(*name)) {
> + reply(521, "Bite me.");
> + return;
> + }
> +
>   if (mkdir(name, 0777) < 0)
>   perror_reply(550, name);
>   else
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message

-- 
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Insane performance regression?

2002-01-20 Thread Poul-Henning Kamp


One, check your malloc option settings.  FreeBSD-current defaults to the
AJ setting to flush out errors but this has a significant performance
hit.

See the malloc(3) manpage for details.

You don't say which version you were running before so this is the most
specific advice I can give you.

Poul-Henning

In message <01c1a16a$ec95cc50$022a17ac@simplex>, "Duraid Madina" writes:
>Hi all,
>
>   I have a CPU-bound (well, 'malloc-bound' ;) program which takes
>about 20 seconds to run on a 'fast' PC (Pentium3-1000, Athlon XP1600
>etc) - the source is available as
>http://www.idesign.fl.net.au/malloc_pain/malloc_pain.tar.gz (NOTE: you
>*will* need GCC 3 (or more recent) to compile it). At any rate, I did
>the cvsup/buildkernel/buildworld thing this morning (I'm running
>5-CURRENT on an SMP box), and now that same program takes about half an
>hour to run, rather than 20 seconds. Curiously, it reports about 20%
>system time (whereas previously there was negligible system time)
>
>   Any idea what might be going on?
>
>   Duraid
>
>P.S. to run it:
>
>gcc -c mt19937b-int.c
>g++ Graph.cpp mt19937b-int.o
>./a.out
>
>Known to compile okay with GCC 3.0.3 and 3.1
>
>
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-hackers" in the body of the message
>

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Insane performance regression?

2002-01-20 Thread Dan Nelson

Bad top-poster, no cookie.

In the last episode (Jan 20), Poul-Henning Kamp said:
> In message <01c1a16a$ec95cc50$022a17ac@simplex>, "Duraid Madina" writes:
> > I have a CPU-bound (well, 'malloc-bound' ;) program which takes
> > about 20 seconds to run on a 'fast' PC (Pentium3-1000, Athlon
> > XP1600 etc) - the source is available as
> > http://www.idesign.fl.net.au/malloc_pain/malloc_pain.tar.gz (NOTE:
> > you *will* need GCC 3 (or more recent) to compile it). At any rate,
> > I did the cvsup/buildkernel/buildworld thing this morning (I'm
> > running 5-CURRENT on an SMP box), and now that same program takes
> > about half an hour to run, rather than 20 seconds. Curiously, it
> > reports about 20% system time (whereas previously there was
> > negligible system time)
>
> One, check your malloc option settings.  FreeBSD-current defaults to the
> AJ setting to flush out errors but this has a significant performance
> hit.

Duraid: were you running 4.* before and just upgraded to -current, or
did you simply bring an older -current box up to date?  If the latter,
you might want to try building different kernels to see if you can
pinpoint the commit that's causing your slowdown.  You will only have
to rebuild the kernel, and a binary search should let you narrow it
down in under 2 hours, I'd say.  I would have suggested looking at
Alfred's SMP file locking commit on 2001-01-13, but if your program
just does malloc()s it shouldn't be affected by that.

-- 
Dan Nelson
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



FreeBSD.org SIte

2002-01-20 Thread MSC Sharp

I was just wondering if the FreeBSD team would accept a new web site from an
emerging web design company.  All work would be done for free of course and
would consist of remodeling the whole or any part of the web site that your
organization requested.  If you are interested please contact me with some
specifications of work you would like done or just a yes or no reply.  If you
accept we will contact you again in a few weeks to show you some samles of our
work.

Thank you,
I can be contacted at [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: FreeBSD.org SIte

2002-01-20 Thread Chris Costello

[Thread moved to freebsd-doc]

On Sunday, January 20, 2002, MSC Sharp wrote:
> I was just wondering if the FreeBSD team would accept a new web site from an
> emerging web design company.  All work would be done for free of course and
> would consist of remodeling the whole or any part of the web site that your
> organization requested.  If you are interested please contact me with some
> specifications of work you would like done or just a yes or no reply.  If you
> accept we will contact you again in a few weeks to show you some samles of our
> work.

   You may want to consult with Nik Clayton and the FreeBSD
Documentation ([EMAIL PROTECTED] and [EMAIL PROTECTED] respectively)
on this.  We are currently in the process of updating the Web
site's layout anyway, making a more extensive use of XML and XSLT
than before (or at least, a more _proper_ use).

   That is, if you're serious about helping. :)

-- 
+---+--+
| Chris Costello| Computer and car salesmen differ in that |
| [EMAIL PROTECTED] | the latter know when they are lying. |
+---+--+

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



patch for network counter implementation (64bit/atomic)

2002-01-20 Thread Michal Mertl

After rather long discussion on arch with no apparent result I have my
patch for STABLE ready.

Sorry to repeat what has been already talked about but there may be people
on hackers who don't read arch.

I've posted 2 patches on
http://home.eunet.cz/mime/syscntr.diff.20020120.gz
and http://home.eunet.cz/mime/netstat.diff.gz (only modifies netstat to be
able to show 64 bit values).

The first one modifies lots of sources in kernel but I believe that most
changes are totally harmless. It modifies all network device driver
sources to use newly defined API for accessing counters (packets, bytes,
errors...). It also modifies some files in /sys/net* to use the same API.
The counters are defined in /sys/net/if.h and
/sys/netinet/{ip|tcp|udp|igmp|icmp}_var.h and their type is changed from
u_long to syscntr_t. The new API is defined in /sys/i386/include/syscntr.h
but is 99% MI - no problem should occur with Alpha and other ports. By
default the syscntr_t is u_int32_t and is accessed non-atomically. This is
probably incorrect but it's the same way it's been done for ages so no new
problem is created. Change of 2 defines in the file makes counters either
64 bit and/or atomic. Other API feature which may end up useless is that
the different counters can be accessed by different type of operation (the
size is always either 32 or 64 bit) - maybe even something not yet
implemented - per cpu.

Other change there is adding support for 64 bit atomic ops to X86 -
unfortunatelly the instruction required for this operation is only or
>=586. So atomic 64 bit operation is possible only on these computers -
but that's maybe also only on SMP machines (>=586) where the atomicity is
strictly needed.

As discussed to death on arch atomicity and 64 bit both add to cost of
accessing the counters. The most common operation is addition - on p3
non-atomic 32 bit cost about 2 clocks, atomic 32 bit 20 clocks, non-atomic
64 bit 7 clocks and atomic 64 bit 50 clocks. For each tcp packet we have
at least 5 counter updates.

The code is perfectly usable on CURRENT too. If there's single request
I'll make sure it fits there 100%.

There's one problem I'm aware of - NETGRAPH. It has some counters
defined in code too and I think it will benefit from the change too. But I
don't now if it's possible to change the types in there (are there NG
drivers not it tree?).

PS: After changing kernel counters from 32 to 64 bit, some of world has to
be rebuild too (to notice the change in structs which contain the
counters). Namely ifconfig, netstat, systat and probably others.

-- 
Michal Mertl
[EMAIL PROTECTED]












To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Hi Friend

2002-01-20 Thread liltator

Warning
Unable to process data: 
multipart/mixed;boundary="=_NextPart_000_1B37_2A92.1000"




RE:

2002-01-20 Thread rjumper

TIRED OF ENDLESSLY POSTING YOUR ONLINE CLASSIFIED AD AND GETTING 
NO RESULTS?

There are over 7000 such sites scattered about the web;
and quite frankly, none of them generate enough traffic to be worth 
your
while. Even when someone finds or visits one of these sites, your
ad is hopelessly lost in a myriad of similar offerings.

Another frustration is search engines. If you are not in the Top 10,
forget about high-traffic on your web site. Not everyone can be
in the Top 10 and stay there; when there are estimates of four million
web pages!

How do we know? We know because that's exactly what we used to do.

The greatest way of marketing this century is undoubtedly direct
e-mail. It's similar to the postman delivering a letter to your
mailbox. There is NO stumbling on to it! The ability to promote your
product, service, website, or MLM/network marketing opportunity to
millions instantly is what advertisers have been dreaming of for over
100 years. We will e-mail your one page promotion to a list of our
general addresses. The greatest part is, it's completely affordable.

---

NOTICE: Absolutely no pornography, chain letters, get rich quick, 
pyramid schemes,
or any threatening or questionable materials. 

---

STANDARD PRICING AND PROCEDURES

---

EXTRACTING:

Our list of general Internet addreses are actually extracted 
from the most popular web sites on the Internet. The addresses are 
verified 
and run through our purification process. The process includes 
addresses
run against our custom remove filter of 2,492 keywords, as well as
through our 192MB remove /flamer list. The EDU, ORG, GOV, MIL, and US
domains are removed, as well as other domains that asked not to
receive e-mail.

---

SET-UP FEE:  $150.00
This will cover the costs of uploading files, Internet Access (ISP),
and software set-up.

---

EVALUATION:  $350.00 (optional)
One of our marketing specialists will evaluate your sales letter, and
offer his/her expertise on how to make it the most successful.

---

STANDARD PRICING: (Emails Delivered)
1 Million- $800.00 per
2 Million- $700.00 per
3 Million & up- $600.00 per

---

SPECIAL OFFER!

This introductory offer of $475.00 includes:

1. Set-Up Fee
2. Evaluation of Sales Letter 
3. 250,000 e-mails delivered

---

PAYMENT POLICY
All services must be paid in full prior to delivery of advertisement.
Under NO CIRCUMSTANCES will any sales or marketing strategies be
discussed until payment is received.
---
If you are serious about Direct Email Marketing--Fax the following
form to (602) 392-8288
--

PLEASE FILL THIS FORM OUT COMPLETELY!

Contact Name: _
Business Name:  __
Business Type:  __
# Years in Business:  _
Address: _
City:   State: __  Zip: __
Country: ___
Email Address: ___
Phone:  __Fax:  

---


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message