OpenBSD's extremely poor network/disk performance?

classic Classic list List threaded Threaded
59 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

Theo de Raadt-2
Ingo Schwarze <[hidden email]> wrote:

> Even if you had, let's say, a whole year to spend full-time, you
> would not really be making any sense right now.  So, could we drop
> this thread, please?

Ingo, you know that's impossible.

These are people on misc, their self-importance and optimism knows
no bounds.

Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

Xiyue Deng
In reply to this post by Ingo Schwarze
Ingo Schwarze <[hidden email]> writes:

> Hi Stuart,
>
> Stuart Longland wrote on Thu, Jan 09, 2020 at 09:07:38AM +1000:
>> Somebody wrote:
>
>>> - If we could clean-room implement a BSD-licensed
>>> EXT3/EXT4/BTRFS/XFS/JFS/whatever, following style(8), would there be
>>> interest in supporting that in OpenBSD?
>
>> I'm hoping it will be more than one person assisting in this,
>> and yes, I include myself in that group.
>
> schwarze@cvs $ grep -Fi longland /cvs/CVSROOT/ChangeLog*                      
> schwarze@cvs $
>
> And https://stuartl.longlandclan.id.au/ lists a single free software
> project, about 190 commits of Python code, with one single contributor.
>
>
> I'm sorry that i have to use somewhat strong wording here, i'm
> generally trying to help making our lists as friendly as possible,
> but in this case, a clear answer is really required.
>
> There is few code that is as difficult as a file system.
> There is few code that is as closely entangled with the hardest
> parts of there kernel like file system code.
> There is few code where touching it is as dangerous as touching
> file system code.
> There are few areas of the system where people get as upset
> when you break it as with file systems.  You literally make people
> lose their personal data, and when they realize something went wrong,
> it's usually too late, the data is usually already gone for good.
>
> You are certainly welcome to contribute if you want to: start with
> sending samll bugfix patches.  Progress to small feature additions
> or small cleanup patches in areas that are not too dangerous.
> Then grow.  Anything beyond that is impossible to predict.
>
> For a newbie, there is really no point in dreaming about
> implementing or changing file systems.
>
> You need to learn what you are capable of and then convince others
> of your abilities *by getting good patches committed*.  Idle talk
> announcing bizarre dreams doesn't really help anyone.
>
> Are you aware that even Bob Beck@ is seriously scared of some
> parts of our file system code, and of touching some parts of it?
> Yes, this Bob Beck, who isn't really all that easily scared:
>
>   https://www.youtube.com/watch?v=GnBbhXBDmwU
>
> One of our most senior developers, regularly and continuously
> contributing since 1997, and among those who understand our
> file system code best.  Most recently, he was among the main
> driving forces behind unveil(2).
>
>
> Becoming able to approximately judge the difficulty and size of
> tasks relative to your own abilities is extremely important when
> you want to contribute to free software.
>
> Even if you had, let's say, a whole year to spend full-time, you
> would not really be making any sense right now.  So, could we drop
> this thread, please?
>
> Yours,
>   Ingo
Some guy asks whether there's any plan to improve file system
performance, the answer given is the code is right there if you want to
contribute.  Then some other guy offers a proposal to start working on
it, and the answer now becomes you are hardly qualified for such kind of
work.

Sorry but such kinds of answers are not helpful, and gives the
(potentially wrong) impression that OpenBSD doesn't welcome
contributions.  It would be better to point out where to start, what
hard problems to solve, what work has been done in this area that people
can continue to work on.

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

Theo de Raadt-2
Xiyue Deng <[hidden email]> wrote:

> Ingo Schwarze <[hidden email]> writes:
>
> > Hi Stuart,
> >
> > Stuart Longland wrote on Thu, Jan 09, 2020 at 09:07:38AM +1000:
> >> Somebody wrote:
> >
> >>> - If we could clean-room implement a BSD-licensed
> >>> EXT3/EXT4/BTRFS/XFS/JFS/whatever, following style(8), would there be
> >>> interest in supporting that in OpenBSD?
> >
> >> I'm hoping it will be more than one person assisting in this,
> >> and yes, I include myself in that group.
> >
> > schwarze@cvs $ grep -Fi longland /cvs/CVSROOT/ChangeLog*                      
> > schwarze@cvs $
> >
> > And https://stuartl.longlandclan.id.au/ lists a single free software
> > project, about 190 commits of Python code, with one single contributor.
> >
> >
> > I'm sorry that i have to use somewhat strong wording here, i'm
> > generally trying to help making our lists as friendly as possible,
> > but in this case, a clear answer is really required.
> >
> > There is few code that is as difficult as a file system.
> > There is few code that is as closely entangled with the hardest
> > parts of there kernel like file system code.
> > There is few code where touching it is as dangerous as touching
> > file system code.
> > There are few areas of the system where people get as upset
> > when you break it as with file systems.  You literally make people
> > lose their personal data, and when they realize something went wrong,
> > it's usually too late, the data is usually already gone for good.
> >
> > You are certainly welcome to contribute if you want to: start with
> > sending samll bugfix patches.  Progress to small feature additions
> > or small cleanup patches in areas that are not too dangerous.
> > Then grow.  Anything beyond that is impossible to predict.
> >
> > For a newbie, there is really no point in dreaming about
> > implementing or changing file systems.
> >
> > You need to learn what you are capable of and then convince others
> > of your abilities *by getting good patches committed*.  Idle talk
> > announcing bizarre dreams doesn't really help anyone.
> >
> > Are you aware that even Bob Beck@ is seriously scared of some
> > parts of our file system code, and of touching some parts of it?
> > Yes, this Bob Beck, who isn't really all that easily scared:
> >
> >   https://www.youtube.com/watch?v=GnBbhXBDmwU
> >
> > One of our most senior developers, regularly and continuously
> > contributing since 1997, and among those who understand our
> > file system code best.  Most recently, he was among the main
> > driving forces behind unveil(2).
> >
> >
> > Becoming able to approximately judge the difficulty and size of
> > tasks relative to your own abilities is extremely important when
> > you want to contribute to free software.
> >
> > Even if you had, let's say, a whole year to spend full-time, you
> > would not really be making any sense right now.  So, could we drop
> > this thread, please?
> >
> > Yours,
> >   Ingo
>
> Some guy asks whether there's any plan to improve file system
> performance, the answer given is the code is right there if you want to
> contribute.

We (the project developers) did not provide that answer.  One of you
typical "posers" suggested it.

> Then some other guy offers a proposal to start working on
> it,

Wow.  He did not offer to start anything like that.  Maybe he'll create
a wiki, or write some words on a mailing list?

> and the answer now becomes you are hardly qualified for such kind of
> work.

I suspect you are also unqualified.

> Sorry but such kinds of answers are not helpful, and gives the
> (potentially wrong) impression that OpenBSD doesn't welcome
> contributions.  It would be better to point out where to start, what
> hard problems to solve, what work has been done in this area that people
> can continue to work on.

Cut the crap.  Those of you posting in this thread are only capable of
writing words of text to a mailing list.

Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

Theo de Raadt-2
In reply to this post by Xiyue Deng
Xiyue Deng <[hidden email]> wrote:

> It would be better to point out where to start, what
> hard problems to solve, what work has been done in this area that people
> can continue to work on.

Looking at that list, noone here owes you any of those.

Do your own homework.

Re-reading the thread is remarkable.  It's a bunch of people who
won't do the work telling us that we need to tell them what work
to do.  A bunch of garbage is coming out of your mouths.

Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

Stuart Longland
In reply to this post by Theo de Raadt-2
On 9/1/20 12:20 pm, Theo de Raadt wrote:
>> and the answer now becomes you are hardly qualified for such kind of
>> work.
> I suspect you are also unqualified.
>

You don't become qualified by writing words on a mailing list… and while
I acknowledge a lack of experience in the area, I do understand the
risks involved and I am willing to give it a try.  ffs is not going
anywhere any time soon.

Contrary to recently-expressed opinion, I have done kernel-level and
bare-metal coding before.  OpenBSD isn't the only OS kernel in existence.

Those interested in helping out: contact me off list, there is little to
be gained by discussing it here.
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

Xiyue Deng
In reply to this post by Theo de Raadt-2
"Theo de Raadt" <[hidden email]> writes:

> Xiyue Deng <[hidden email]> wrote:
>
>> Ingo Schwarze <[hidden email]> writes:
>>
>> > Hi Stuart,
>> >
>> > Stuart Longland wrote on Thu, Jan 09, 2020 at 09:07:38AM +1000:
>> >> Somebody wrote:
>> >
>> >>> - If we could clean-room implement a BSD-licensed
>> >>> EXT3/EXT4/BTRFS/XFS/JFS/whatever, following style(8), would there be
>> >>> interest in supporting that in OpenBSD?
>> >
>> >> I'm hoping it will be more than one person assisting in this,
>> >> and yes, I include myself in that group.
>> >
>> > schwarze@cvs $ grep -Fi longland /cvs/CVSROOT/ChangeLog*                      
>> > schwarze@cvs $
>> >
>> > And https://stuartl.longlandclan.id.au/ lists a single free software
>> > project, about 190 commits of Python code, with one single contributor.
>> >
>> >
>> > I'm sorry that i have to use somewhat strong wording here, i'm
>> > generally trying to help making our lists as friendly as possible,
>> > but in this case, a clear answer is really required.
>> >
>> > There is few code that is as difficult as a file system.
>> > There is few code that is as closely entangled with the hardest
>> > parts of there kernel like file system code.
>> > There is few code where touching it is as dangerous as touching
>> > file system code.
>> > There are few areas of the system where people get as upset
>> > when you break it as with file systems.  You literally make people
>> > lose their personal data, and when they realize something went wrong,
>> > it's usually too late, the data is usually already gone for good.
>> >
>> > You are certainly welcome to contribute if you want to: start with
>> > sending samll bugfix patches.  Progress to small feature additions
>> > or small cleanup patches in areas that are not too dangerous.
>> > Then grow.  Anything beyond that is impossible to predict.
>> >
>> > For a newbie, there is really no point in dreaming about
>> > implementing or changing file systems.
>> >
>> > You need to learn what you are capable of and then convince others
>> > of your abilities *by getting good patches committed*.  Idle talk
>> > announcing bizarre dreams doesn't really help anyone.
>> >
>> > Are you aware that even Bob Beck@ is seriously scared of some
>> > parts of our file system code, and of touching some parts of it?
>> > Yes, this Bob Beck, who isn't really all that easily scared:
>> >
>> >   https://www.youtube.com/watch?v=GnBbhXBDmwU
>> >
>> > One of our most senior developers, regularly and continuously
>> > contributing since 1997, and among those who understand our
>> > file system code best.  Most recently, he was among the main
>> > driving forces behind unveil(2).
>> >
>> >
>> > Becoming able to approximately judge the difficulty and size of
>> > tasks relative to your own abilities is extremely important when
>> > you want to contribute to free software.
>> >
>> > Even if you had, let's say, a whole year to spend full-time, you
>> > would not really be making any sense right now.  So, could we drop
>> > this thread, please?
>> >
>> > Yours,
>> >   Ingo
>>
>> Some guy asks whether there's any plan to improve file system
>> performance, the answer given is the code is right there if you want to
>> contribute.
>
> We (the project developers) did not provide that answer.  One of you
> typical "posers" suggested it.
>
>> Then some other guy offers a proposal to start working on
>> it,
>
> Wow.  He did not offer to start anything like that.  Maybe he'll create
> a wiki, or write some words on a mailing list?
>
>> and the answer now becomes you are hardly qualified for such kind of
>> work.
>
> I suspect you are also unqualified.
I am, which is why I didn't propose anything yet.

>
>> Sorry but such kinds of answers are not helpful, and gives the
>> (potentially wrong) impression that OpenBSD doesn't welcome
>> contributions.  It would be better to point out where to start, what
>> hard problems to solve, what work has been done in this area that people
>> can continue to work on.
>
> Cut the crap.  Those of you posting in this thread are only capable of
> writing words of text to a mailing list.

I was hoping that Stuart's email was the a new start aside from that
troll thread.  But well.

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

gwes-2
Suggestion: to improve file system performance,
first document the bad behavior in detail.

Begin with examples of traces/logs of disk accesses associated
with file system operations.

Include scenarios (one hopes reproducible ones) to provoke
bad behavior.

Are reads worse than writes? Sequential vs. random?
Interleaved r/w on one file? On more than one file simultaneously?

Examples from other O/S which are better or worse?

Without this very detailed data it's all noise.

Being able to get good traces & correlate them with OS activity
shows at least some competence dealing with OS internals.

geoff steckel

Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

Xiyue Deng
gwes <[hidden email]> writes:

> Suggestion: to improve file system performance,
> first document the bad behavior in detail.
>
> Begin with examples of traces/logs of disk accesses associated
> with file system operations.
>
> Include scenarios (one hopes reproducible ones) to provoke
> bad behavior.
>
> Are reads worse than writes? Sequential vs. random?
> Interleaved r/w on one file? On more than one file simultaneously?
>
> Examples from other O/S which are better or worse?
>
> Without this very detailed data it's all noise.
>
> Being able to get good traces & correlate them with OS activity
> shows at least some competence dealing with OS internals.
>
> geoff steckel
Thanks Geoff!  I was looking for this kind of guide so that I can do
something not noisy.

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenBSD's extremely poor network/disk performance?

Steve Litt
In reply to this post by Hamdi Akyol
On Wed, 8 Jan 2020 17:57:37 +0300
Hamd <[hidden email]> wrote:

 
> Under less than 24 hours, after my post, the misc has received 2 or 3
> brand new questions/posts regarding slow*. The problem is, well,
> obviously not me, personally.
> For the Dev Team (All of 'em. Volunteer, beer-teer, pay-teer ones): I
> regretfully think, the time of changing that filesystem older than my
> 2xgrandfather, has arrived.

Just speaking anecdotally for myself: I've never noticed especially
slow disk performance with OpenBSD. If OpenBSD's disk performance
really is 5 or 10 times slower than Linux, perhaps in most situations
disk caching makes the difference negligible.

If you really want to see an OS with slow disks that dramatically slow
down the whole system, get yourself a copy of OpenSolaris and load it
on a PC. Very nice, very stable, but everything takes 4 times as long.
 
SteveT

Steve Litt
January 2020 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust

Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

Consus-2
In reply to this post by Xiyue Deng
On 18:15 Wed 08 Jan, Xiyue Deng wrote:
> It would be better to point out where to start, what hard problems to
> solve, what work has been done in this area that people can continue
> to work on.

They don't remember as there is no bugtracker.

Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

Janne Johansson-3
In reply to this post by Ingo Schwarze
Den tors 9 jan. 2020 kl 02:11 skrev Ingo Schwarze <[hidden email]>:

>
> Are you aware that even Bob Beck@ is seriously scared of some
> parts of our file system code, and of touching some parts of it?
> Yes, this Bob Beck, who isn't really all that easily scared:
>
>   https://www.youtube.com/watch?v=GnBbhXBDmwU
>
> One of our most senior developers, regularly and continuously
> contributing since 1997, and among those who understand our
> file system code best.
>

And here I thought you would post thib@s talk literally named
"Things that makes Bob scream" from the f2k9/Slackathon conf:

https://www.youtube.com/watch?v=HTD9Gow1wTU

--
May the most significant bit of your life be positive.
Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

Stefan Sperling-5
In reply to this post by Consus-2
On Thu, Jan 09, 2020 at 11:02:17AM +0300, Consus wrote:
> On 18:15 Wed 08 Jan, Xiyue Deng wrote:
> > It would be better to point out where to start, what hard problems to
> > solve, what work has been done in this area that people can continue
> > to work on.
>
> They don't remember as there is no bugtracker.

When people report actual bugs, they get fixed so fast that tracking
them over days or weeks would be pointless.

"""
We thank Theo de Raadt and the OpenBSD developers for their incredibly
quick response: they published patches for these vulnerabilities less
than 40 hours after our initial contact.
""" -- Qualys

Any non-critical stuff which gets reported ("my printer/wifi/usb doesn't work",
"kernel does not boot on my new laptop", "my system works but is slow") just
lands in an endless pile of problems that someone might eventually decide to
work on if they run into it again. Such issues happen over and over again,
all the time. Any developer picking them up ASAP over and over would burn out,
just like they do in companies with issue-tracker driven workflows. That's why
people demanding loudly to get such issues fixed are told to shut up.

And keep in mind that at any given moment there are only about 50 to 100
people doing actual work here. The rest of the world is busy elsewhere or
slacking.

Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

Consus-2
On 10:45 Thu 09 Jan, Stefan Sperling wrote:

> On Thu, Jan 09, 2020 at 11:02:17AM +0300, Consus wrote:
> > On 18:15 Wed 08 Jan, Xiyue Deng wrote:
> > > It would be better to point out where to start, what hard problems to
> > > solve, what work has been done in this area that people can continue
> > > to work on.
> >
> > They don't remember as there is no bugtracker.
>
> When people report actual bugs, they get fixed so fast that tracking
> them over days or weeks would be pointless.
>
> """
> We thank Theo de Raadt and the OpenBSD developers for their incredibly
> quick response: they published patches for these vulnerabilities less
> than 40 hours after our initial contact.
> """ -- Qualys
>
> Any non-critical stuff which gets reported ("my printer/wifi/usb doesn't work",
> "kernel does not boot on my new laptop", "my system works but is slow") just
> lands in an endless pile of problems that someone might eventually decide to
> work on if they run into it again. Such issues happen over and over again,
> all the time. Any developer picking them up ASAP over and over would burn out,
> just like they do in companies with issue-tracker driven workflows. That's why
> people demanding loudly to get such issues fixed are told to shut up.
>
> And keep in mind that at any given moment there are only about 50 to 100
> people doing actual work here. The rest of the world is busy elsewhere or
> slacking.

Relax, it was a joke.

zap
Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

zap
In reply to this post by Theo de Raadt-2


On 01/08/2020 09:25 PM, Theo de Raadt wrote:

> Xiyue Deng <[hidden email]> wrote:
>
>> It would be better to point out where to start, what
>> hard problems to solve, what work has been done in this area that people
>> can continue to work on.
> Looking at that list, noone here owes you any of those.
>
> Do your own homework.
>
> Re-reading the thread is remarkable.  It's a bunch of people who
> won't do the work telling us that we need to tell them what work
> to do.  A bunch of garbage is coming out of your mouths.
>
The average user probably knows nothing about the hard work it takes to
make an OS.  Don't get me wrong, I disagree with BSD on some stances,
but I am not the one who has to do the hard work.  So there's that...


Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

Stefan Sperling-5
In reply to this post by Consus-2
On Thu, Jan 09, 2020 at 12:47:31PM +0300, Consus wrote:
> Relax, it was a joke.

Whatever, what I wrote wasn't just directed at you.

misc@ sucks a lot lately.

Reply | Threaded
Open this post in threaded view
|

Re: OpenBSD's extremely poor network/disk performance?

Hamdi Akyol
In reply to this post by Joe Greco
Joe, are you a joke? Please stop insulting me, this is not
my/your_personal_fancy_forum.

This will be my last post here in misc.

Default setups, no config. changes.
Just patches installed.
Same hardware.

FreeBSD:
freebsd@test:~ # time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=50000
&& sync"
50000+0 records in
50000+0 records out
204800000 bytes transferred in 0.239590 secs (854792500 bytes/sec)
0.000u 0.195s 0:00.25 76.0%     22+198k 0+1568io 0pf+0w

Result: *854.79 MB/s disk speed*

freebsd@test:~ # uname -a
FreeBSD test.local 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC  amd64

OpenBSD:
test$ time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=50000 && sync"
50000+0 records in
50000+0 records out
204800000 bytes transferred in 12.303 secs (16645247 bytes/sec)
    0m12.32s real     0m00.13s user     0m01.28s system

Result: *16.64 MB/s disk speed*

test$ uname -a
OpenBSD test.local 6.6 GENERIC#3 amd64

You all guys, please don't get me wrong in any way, I truly adore
cleanness, stability and security of OpenBSD, huge efforts of all the dev
team is really, much appreciated!

I agree when it comes to OpenBSD, of course, security comes FIRST. But in
2020, a speed of 16 megabytes per second...hurts the users. A lot.

I really wish I could do contribute the code somehow..*sighs

Regards.




Joe Greco <[hidden email]>, 8 Oca 2020 Çar, 18:29 tarihinde şunu yazdı:

> On Wed, Jan 08, 2020 at 05:57:37PM +0300, Hamd wrote:
> > Under less than 24 hours, after my post, the misc has received 2 or 3
> brand
> > new questions/posts regarding slow*.
>
> Well, in the case of my issue, I am reasonably certain that this isn't
> an issue with LibreSSL.  I raised it as an issue of simply not knowing
> how to get it to do what I need at the speeds it is clearly capable
> of, on i386.  It works fine and at approximately OpenSSL speeds on
> amd64.
>
> > The problem is, well, obviously not me, personally.
>
> I beg to differ.
>
> Your repurposing my question for your own ends in an attempt to
> categorize it as an general OpenBSD performance issue is, in my
> opinion, full of **it.
>
> This is not helpful to those of us who are asking legitimate
> questions of those who are more familiar with these projects.
> I know I've made a dumb mistake of some sort and I was hoping
> someone would point it out.
>
> If you do not like the product, don't use it.  Or submit a patch
> to fix it.
>
> ... JG
> --
> Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
> "The strain of anti-intellectualism has been a constant thread winding its
> way
> through our political and cultural life, nurtured by the false notion that
> democracy means that 'my ignorance is just as good as your
> knowledge.'"-Asimov
>
Reply | Threaded
Open this post in threaded view
|

Re: OpenBSD's extremely poor network/disk performance?

Infoomatic
just out of curiosity: did you do the FreeBSD test on ZFS with
compression enabled?


Am 09.01.20 um 15:22 schrieb Hamd:

> Joe, are you a joke? Please stop insulting me, this is not
> my/your_personal_fancy_forum.
>
> This will be my last post here in misc.
>
> Default setups, no config. changes.
> Just patches installed.
> Same hardware.
>
> FreeBSD:
> freebsd@test:~ # time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=50000
> && sync"
> 50000+0 records in
> 50000+0 records out
> 204800000 bytes transferred in 0.239590 secs (854792500 bytes/sec)
> 0.000u 0.195s 0:00.25 76.0%     22+198k 0+1568io 0pf+0w
>
> Result: *854.79 MB/s disk speed*
>
> freebsd@test:~ # uname -a
> FreeBSD test.local 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC  amd64
>
> OpenBSD:
> test$ time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=50000 && sync"
> 50000+0 records in
> 50000+0 records out
> 204800000 bytes transferred in 12.303 secs (16645247 bytes/sec)
>      0m12.32s real     0m00.13s user     0m01.28s system
>
> Result: *16.64 MB/s disk speed*
>
> test$ uname -a
> OpenBSD test.local 6.6 GENERIC#3 amd64
>
> You all guys, please don't get me wrong in any way, I truly adore
> cleanness, stability and security of OpenBSD, huge efforts of all the dev
> team is really, much appreciated!
>
> I agree when it comes to OpenBSD, of course, security comes FIRST. But in
> 2020, a speed of 16 megabytes per second...hurts the users. A lot.
>
> I really wish I could do contribute the code somehow..*sighs
>
> Regards.
>
>
>
>
> Joe Greco <[hidden email]>, 8 Oca 2020 Çar, 18:29 tarihinde şunu yazdı:
>
>> On Wed, Jan 08, 2020 at 05:57:37PM +0300, Hamd wrote:
>>> Under less than 24 hours, after my post, the misc has received 2 or 3
>> brand
>>> new questions/posts regarding slow*.
>> Well, in the case of my issue, I am reasonably certain that this isn't
>> an issue with LibreSSL.  I raised it as an issue of simply not knowing
>> how to get it to do what I need at the speeds it is clearly capable
>> of, on i386.  It works fine and at approximately OpenSSL speeds on
>> amd64.
>>
>>> The problem is, well, obviously not me, personally.
>> I beg to differ.
>>
>> Your repurposing my question for your own ends in an attempt to
>> categorize it as an general OpenBSD performance issue is, in my
>> opinion, full of **it.
>>
>> This is not helpful to those of us who are asking legitimate
>> questions of those who are more familiar with these projects.
>> I know I've made a dumb mistake of some sort and I was hoping
>> someone would point it out.
>>
>> If you do not like the product, don't use it.  Or submit a patch
>> to fix it.
>>
>> ... JG
>> --
>> Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
>> "The strain of anti-intellectualism has been a constant thread winding its
>> way
>> through our political and cultural life, nurtured by the false notion that
>> democracy means that 'my ignorance is just as good as your
>> knowledge.'"-Asimov
>>

Reply | Threaded
Open this post in threaded view
|

Re: OpenBSD's extremely poor network/disk performance?

Consus-2
In reply to this post by Hamdi Akyol
On 17:22 Thu 09 Jan, Hamd wrote:

> Joe, are you a joke? Please stop insulting me, this is not
> my/your_personal_fancy_forum.
>
> This will be my last post here in misc.
>
> Default setups, no config. changes.
> Just patches installed.
> Same hardware.
>
> FreeBSD:
> freebsd@test:~ # time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=50000
> && sync"
> 50000+0 records in
> 50000+0 records out
> 204800000 bytes transferred in 0.239590 secs (854792500 bytes/sec)
> 0.000u 0.195s 0:00.25 76.0%     22+198k 0+1568io 0pf+0w
>
> Result: *854.79 MB/s disk speed*
>
> freebsd@test:~ # uname -a
> FreeBSD test.local 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC  amd64
>
> OpenBSD:
> test$ time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=50000 && sync"
> 50000+0 records in
> 50000+0 records out
> 204800000 bytes transferred in 12.303 secs (16645247 bytes/sec)
>     0m12.32s real     0m00.13s user     0m01.28s system
>
> Result: *16.64 MB/s disk speed*
>
> test$ uname -a
> OpenBSD test.local 6.6 GENERIC#3 amd64
>
> You all guys, please don't get me wrong in any way, I truly adore
> cleanness, stability and security of OpenBSD, huge efforts of all the dev
> team is really, much appreciated!
>
> I agree when it comes to OpenBSD, of course, security comes FIRST. But in
> 2020, a speed of 16 megabytes per second...hurts the users. A lot.
>
> I really wish I could do contribute the code somehow..*sighs
>
> Regards.

Please, stop using dd as a benchmark. Use fio or similar programs.

Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

Ingo Schwarze
In reply to this post by Janne Johansson-3
Hi Janne,

Janne Johansson wrote on Thu, Jan 09, 2020 at 09:49:43AM +0100:
> Den tors 9 jan. 2020 kl 02:11 skrev Ingo Schwarze <[hidden email]>:

>> Are you aware that even Bob Beck@ is seriously scared of some
>> parts of our file system code, and of touching some parts of it?
>> Yes, this Bob Beck, who isn't really all that easily scared:
>>
>>   https://www.youtube.com/watch?v=GnBbhXBDmwU
>>
>> One of our most senior developers, regularly and continuously
>> contributing since 1997, and among those who understand our
>> file system code best.

> And here I thought you would post thib@s talk literally named
> "Things that makes Bob scream" from the f2k9/Slackathon conf:
>
> https://www.youtube.com/watch?v=HTD9Gow1wTU

Cool, i wasn't even aware of thib@'s talk back then.  That was the
very first year i ever took part in a hackathon, and it wasn't that
one.  But yeah, that talk certainly relates to the point i was
trying to make.  Not my area of work really, but as far as i
understand, some things mentioned in the talk have changed a lot,
while others didn't at all, and Bob certainly still has plenty of
opportunity for screaming.  Loudly.  Even though that talk was
certainly hilarious, file systems still aren't a laughing matter.

Thanks for the link,
  Ingo

Reply | Threaded
Open this post in threaded view
|

Re: OpenBSD's extremely poor network/disk performance?

Karel Gardas
In reply to this post by Hamdi Akyol
On 1/9/20 3:22 PM, Hamd wrote:
> FreeBSD:
> freebsd@test:~ # time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=50000
> && sync"
> 50000+0 records in
> 50000+0 records out
> 204800000 bytes transferred in 0.239590 secs (854792500 bytes/sec)
> 0.000u 0.195s 0:00.25 76.0%     22+198k 0+1568io 0pf+0w
>
> Result: *854.79 MB/s disk speed*

I'm afraid a lot of those data are still in RAM waiting for fs sync. At
least do sync which is whole sys sync and add time of it to to the time
of dd. It'll still not be 100% accurate, but at least more realistic...

> OpenBSD:
> test$ time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=50000 && sync"
> 50000+0 records in
> 50000+0 records out
> 204800000 bytes transferred in 12.303 secs (16645247 bytes/sec)
>      0m12.32s real     0m00.13s user     0m01.28s system
>
> Result: *16.64 MB/s disk speed*
>
> test$ uname -a
> OpenBSD test.local 6.6 GENERIC#3 amd64

As someone already recommended you, you need to provide at least dmesg.


123