Re: CURRENT slow and shaky network stability

[Adrian Chadd]

Can you try 'ifconfig wlan0 promisc' instead and see if that helps?



-a
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT slow and shaky network stability

[Poul-Henning Kamp]

I have been trying to capture a packet trace for the breaking SSH
and while not a statistically rigid conclusion, it doesnt seem
to happen when I run a tcpdump on wlan0.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about cam 4K quirks

[Steven Hartland]

On 11/04/2016 15:24, Tomoaki AOKI wrote:

Thanks for your answer!

On Sun, 10 Apr 2016 16:15:56 +0100
Steven Hartland  wrote:



On 10/04/2016 15:35, Tomoaki AOKI wrote:

On Sun, 10 Apr 2016 06:59:04 -0600
Alan Somers  wrote:


On Sun, Apr 10, 2016 at 12:56 AM, Tomoaki AOKI 
wrote:


Hi. Maybe freebsd-hardware list would be the right place, but it's not
so active. :-(

Is 4K quirks needed for every HDDs/SSDs having physical sector size
4096?

If so, I would be able to provide patch for Crucial M550 and MX200.
(Possibly covers other models [BX200 etc.] by abstraction.)

M550(1TB):  device model  Crucial CT1024M550SSD1
firmware revision MU01
MX200(1TB): device model  Crucial CT1024MX200SSD1
firmware revision MU03
  -> Abstracted with "Crucial CT*SSD*" or "Crucial CT*", as the part
 "1024" should vary with its capacity and can be 3 to 4 digits
 for now. I tried the former and confirmed "quirks=0x1<4K>"
 appears, which doesn't appear without adding the entry.


If not, is it sufficient if `camcontrol identify ` states
"physical 4096" on "sector size" line for everything in kernel and
related components (i.e., zfs-related ones)?


Regards.

You only need quirk entries if the device fails to identify its physical
size correctly.  If "camcontrol identify" states "physical 4096", then
you're probably ok, but it's not the best place to ask.  "camcontrol
identify" asks the device directly, whereas "diskinfo -v" asks the kernel.
If "diskinfo -v" says "4096 stripesize" then you're definitely ok.

-Alan

Thanks for clarification.

Tried "diskinfo -v" as you noted (of course running the kernel without
adding quirks entry) and confirmed it saying "4096 # stripesize".
So it's already OK with current ata_da.c and scsi_da.c (no quirks is
needed).

OTOH, trying with Samsung 850 evo (the last one I have for now,
having quirks entry in current source), "diskinfo -v" says "4096
# stripesize" while "camcontrol identify" says "physical 512".
This should be why quirks entries are needed (and implemented) for it.

Correct, manufactures took the cop out route and return 512 for both
logical and physical sizes to avoid issues with bad OS support.
SSD's a particularly lazy in this regard.

I think stripesize should be primarily for RAID configuration, but
after 4k physical sectored drives  (so called AFT drives) appears,
applied to even for single drive configuration, too. Right?

stripesize simply gives a hit as to performance when accessing the device.

So now FreeBSD's ZFS defaults ashift 12, if I remember correctly, to
align datasets with 4k.
ZFS calculates the most suitable given the reports physical and logical 
sector sizes, technically the default is ashift 9 unless altered by 
setting vfs.zfs.min_auto_ashift.

And UFS has minimum blocksize of 4k (defaults
8k). And more, now gpart can align partitions as root specifies.


If so, as writing blocks smaller than stripesize (except for the last
block of a file) is nonsense for RAID configuration, all write access
to HDDs/SSDs are constrained to use stripesize for minimum block size,
right?

Nope, sectorsize constrains that.

So possibly some filesystems can be mis-aligned even if the start point
is properly aligned.

  *Mis-aligned fragments should be allowed, though.


stripesize is only used as a way to help tune filesystem access patterns
e.g. in ZFS it is used to help determine the ashift value which in turn
determines the minimum allocatable block size. This helps optimise
performance while sacrificing storage space i.e. causing wastage.

Exactly. :-)
But there's large possibility of severe performance degradation caused
by mis-aligned blocks, especially in HDD, and the capacities of HDDs
became large, even in 2.5inch form factor. Defaulting block size to
physical sector size would be reasonable, if any option to downsize to
512 bytes is provided.

That would be a step back, correcting the offset would be the better fix.

  *If I remember correctly, block size of UFS is 4096 bytes at minimum,
   but supports 512 bytes fragments for small files (and to concentrate
   tail portions of large files). It would be in many cases reasonable
   trade-off, too.

I don't use UFS so couldn't comment.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about cam 4K quirks

[Tomoaki AOKI]

Thanks for your answer!

On Sun, 10 Apr 2016 16:15:56 +0100
Steven Hartland  wrote:

> 
> 
> On 10/04/2016 15:35, Tomoaki AOKI wrote:
> > On Sun, 10 Apr 2016 06:59:04 -0600
> > Alan Somers  wrote:
> >
> >> On Sun, Apr 10, 2016 at 12:56 AM, Tomoaki AOKI 
> >> wrote:
> >>
> >>> Hi. Maybe freebsd-hardware list would be the right place, but it's not
> >>> so active. :-(
> >>>
> >>> Is 4K quirks needed for every HDDs/SSDs having physical sector size
> >>> 4096?
> >>>
> >>> If so, I would be able to provide patch for Crucial M550 and MX200.
> >>> (Possibly covers other models [BX200 etc.] by abstraction.)
> >>>
> >>>M550(1TB):  device model  Crucial CT1024M550SSD1
> >>>firmware revision MU01
> >>>MX200(1TB): device model  Crucial CT1024MX200SSD1
> >>>firmware revision MU03
> >>>  -> Abstracted with "Crucial CT*SSD*" or "Crucial CT*", as the part
> >>> "1024" should vary with its capacity and can be 3 to 4 digits
> >>> for now. I tried the former and confirmed "quirks=0x1<4K>"
> >>> appears, which doesn't appear without adding the entry.
> >>>
> >>>
> >>> If not, is it sufficient if `camcontrol identify ` states
> >>> "physical 4096" on "sector size" line for everything in kernel and
> >>> related components (i.e., zfs-related ones)?
> >>>
> >>>
> >>> Regards.
> >>
> >> You only need quirk entries if the device fails to identify its physical
> >> size correctly.  If "camcontrol identify" states "physical 4096", then
> >> you're probably ok, but it's not the best place to ask.  "camcontrol
> >> identify" asks the device directly, whereas "diskinfo -v" asks the kernel.
> >> If "diskinfo -v" says "4096 stripesize" then you're definitely ok.
> >>
> >> -Alan
> > Thanks for clarification.
> >
> > Tried "diskinfo -v" as you noted (of course running the kernel without
> > adding quirks entry) and confirmed it saying "4096 # stripesize".
> > So it's already OK with current ata_da.c and scsi_da.c (no quirks is
> > needed).
> >
> > OTOH, trying with Samsung 850 evo (the last one I have for now,
> > having quirks entry in current source), "diskinfo -v" says "4096
> > # stripesize" while "camcontrol identify" says "physical 512".
> > This should be why quirks entries are needed (and implemented) for it.
> Correct, manufactures took the cop out route and return 512 for both 
> logical and physical sizes to avoid issues with bad OS support.
> SSD's a particularly lazy in this regard.
> > I think stripesize should be primarily for RAID configuration, but
> > after 4k physical sectored drives  (so called AFT drives) appears,
> > applied to even for single drive configuration, too. Right?
> stripesize simply gives a hit as to performance when accessing the device.

So now FreeBSD's ZFS defaults ashift 12, if I remember correctly, to
align datasets with 4k. And UFS has minimum blocksize of 4k (defaults
8k). And more, now gpart can align partitions as root specifies.

> > If so, as writing blocks smaller than stripesize (except for the last
> > block of a file) is nonsense for RAID configuration, all write access
> > to HDDs/SSDs are constrained to use stripesize for minimum block size,
> > right?
> Nope, sectorsize constrains that.

So possibly some filesystems can be mis-aligned even if the start point
is properly aligned.

 *Mis-aligned fragments should be allowed, though.

> 
> stripesize is only used as a way to help tune filesystem access patterns 
> e.g. in ZFS it is used to help determine the ashift value which in turn 
> determines the minimum allocatable block size. This helps optimise 
> performance while sacrificing storage space i.e. causing wastage.
> 
>  Regards
>  Steve

Exactly. :-)
But there's large possibility of severe performance degradation caused
by mis-aligned blocks, especially in HDD, and the capacities of HDDs
became large, even in 2.5inch form factor. Defaulting block size to
physical sector size would be reasonable, if any option to downsize to
512 bytes is provided.

 *If I remember correctly, block size of UFS is 4096 bytes at minimum,
  but supports 512 bytes fragments for small files (and to concentrate
  tail portions of large files). It would be in many cases reasonable
  trade-off, too.


Regards.

-- 
Tomoaki AOKIjunch...@dec.sakura.ne.jp
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: stall-free memory reads ? (possibly stale) ?

[Luigi Rizzo]

thank you, much appreciated.

On Fri, Apr 8, 2016 at 11:22 PM, Slawa Olhovchenkov  wrote:

> On Fri, Apr 08, 2016 at 06:24:16PM +0200, Luigi Rizzo wrote:
>
> > Hi,
> > I have an application with two threads sharing a memory variable,
> > one continuously writing, one continuously reading.
> >
> > Because of the way my system works, the reader can tolerate reading
> > stale data, but it should not stall on memory reads (the line
> > is on the local cache for the reader, just might be invalidated).
> >
> > I was wondering if there is some way (either generic or
> > x86-specific, either simple or convoluted, possibly using
> > multiple versions of the shared variable in different cache
> > lines) to make sure that reads never stalls (or, equivalently,
> > let me read stale values from the cache) ?
> >
> > I have done some experiments and on a single-socket machines
> > the stallled reads take some 50ns; on a dual socket machine
> > the stall penalty grows to about 200ns.
>
> Can this link help to you?
>
> https://tu-dresden.de/die_tu_dresden/zentrale_einrichtungen/zih/forschung/projekte/benchit/2015_ICPP_authors_version.pdf
>
>


-- 
-+---
 Prof. Luigi RIZZO, ri...@iet.unipi.it  . Dip. di Ing. dell'Informazione
 http://www.iet.unipi.it/~luigi/. Universita` di Pisa
 TEL  +39-050-2217533   . via Diotisalvi 2
 Mobile   +39-338-6809875   . 56122 PISA (Italy)
-+---
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Fwd: WIFI urtwn possibly broken on 297561

[Otacílio de Araújo Ramos Neto]

Em seg, 11 de abr de 2016 06:05, Anton Shterenlikht 
escreveu:

> >
> >Hi!
> >
> >this is because we don't have A-MPDU RX aging on by default. So, if
> >there are holes in the sequence number space, FreeBSD's reordering
> >logic doesn't flush frames up until it's received /all/ the traffic.
> >
> >I've just enabled it by default in -HEAD now. That should fix it.
> >Otacilio, you should be able to fix it locally by adding options
> >IEEE80211_AMPDU_AGE to your kernel config file and recompiling.
> >
> >Sorry!
>
> Is this urtwn PR related to this:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205477
>
> Thanks
>
> Anton
>

I can't say that yes  or no because I have testes only on CURRENT and the
bug report is related to 10. But, the issue don't look related. In my case
a previous version of CURRENT works fine and after a update to a new
revision it stop works, but only under load. It is not related to
initialization problem (I think).

[]'S
-Otacilio

>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: WIFI urtwn possibly broken on 297561

[Anton Shterenlikht]

>
>Hi!
>
>this is because we don't have A-MPDU RX aging on by default. So, if
>there are holes in the sequence number space, FreeBSD's reordering
>logic doesn't flush frames up until it's received /all/ the traffic.
>
>I've just enabled it by default in -HEAD now. That should fix it.
>Otacilio, you should be able to fix it locally by adding options
>IEEE80211_AMPDU_AGE to your kernel config file and recompiling.
>
>Sorry!

Is this urtwn PR related to this:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205477

Thanks

Anton
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"