Currently, there appear to be two issues with the RPi3 B+'s LAN7515 chip which can significantly affect performance (and which will need fixes in the customized lan78xx driver, most likely). As far as I can tell, these affect both 64 and 32-bit users, all distros.

The first issue occurs when connecting your RPi3 B+ to an Ethernet switch that does not have flow control turned on (as is the case in many datacentres, for example). RPF engineer comment (quotes below all from this thread on the forums):

Been hitting the ethernet with a stick for the last few days, that stick being iperf3. I have been testing the onboard, and two different USB->GigE dongles.

The main conclusion we have come to - if your switch does NOT have flow control turned on, you will suffer a large drop in performance. This is due to the Pi being unable to service incoming data at gig speeds, and therefore a lot of retries are required for dropped frames.

[...]

Finally, we are talking to Microchip to see what can be done to improve performance. It's their chip and their driver. However, we are still investigating.

The second issue concerns bad Ethernet performance once a certain amount of data (around 2GB?) has been transferred. RPF engineer comment:

I have a suspicion I'm also having related network troubles on my 3B+. If I copy more than a few GB via SMB, the 3B+ network becomes unreliable and stops being able to copy files. Extremely frustrating. I did set flow control to on in my Netgear switch, and that meant that failures took longer to occur and copy speeds were a little higher (~18MB/s), but the same problem still occurs.

For now I've gone back to my 3B. Should I be returning my 3B+?

We have had a number of reports on large transfers dying when using Samba . I think its unrelated to the issue in this thread, but it is being looked in to.

I have personally experienced this (I think), where a large rsync backup of my RPi3 B+ build server choked (repeatedly) about half way (several GB) through, connected over a local LAN (I have never had any issues running the same rsync script on an RPi3 B).

Temporary Workaround

If you are using your RPi3 B+ to provide production services over Ethernet, I recommend using ethtool to reduce the advertised performance to 100Mbit (that of the old RPi3B's adaptor) pro tem. This workaround seems to prevent the problems occurring.

NB: If you only use your RPi3 B+'s Ethernet for light access (e.g. ssh), or use your RPi3 B+'s WiFi networking primarily, or use an RPi3 B, you need take no action at this stage.

When a fix to the kernel driver (covering both the above issues) is released, I'll post again here, at which point you can simply delete the /etc/local.d/slow-down-eth0.start file, if you are using it.

That might explain a few things, I was doing some really big stuff and had a crash.
Mind you, it was deliberate stress testing
I will try with 100Mbs setting.
Sounds like WiFi may be better till fixes come down.
Might try 5GHz band now the I have Pi's that can do that.

What are the cpu, gpu, sdram settings?
How to find them and change them in Gentoo64?
I want to try changing the sdram to 500MHz on my locking combo Pi3B+ /SDcard.

I have looked at this, it's interesting, still not quite sure what the 'official' recommended settings are right now for optimal RPi3B+ stability yet. Once this settles down I will update the relevant package for the Gentoo image.

In any case, the file you need to edit is /boot/config.txt; do this as root (sudo mousepad /boot/config.txt &>dev/null& or similar).

You can add an RPi3B+ specific stanza to the end, and then put in any desired settings there, for example add:

I was aware of it being one way to fake more memory, but can it be used for swap?
For normal Gentoo64, not for the big compiler version that needs 4GB swap etc.
Would it be of any use for the normal desktop user?

I've just posted a v1.2.2 release of my bootable 64-bit Gentoo image for the RPi3 (model B and B+) on GitHub (here, includes full download instructions).

A changelog from the prior release image (with upgrade instructions) may be viewed here, but in summary:

Migrated the default binary kernel package from bcmrpi3-kernel-bin to bcmrpi3-kernel-bis-bin; the latter uses a slightly tweaked version of the upstream bcmrpi3_defconfig via this weekly autobuild (to which, incidentally, config-change PRs will be accepted for review). The original bcmrpi3-kernel-bin package (and autobuild) will continue to be supported, and indeed you can easily switch to this version if you desire (just run, as root, "emerge -av1 sys-kernel/bcmrpi3-kernel-bin && reboot"). However, having the ability to tweak the configuration (and possibly kernel source in future) provides additional flexibility. For example, in this release KVM is supported (see this thread) and the image ships with app-emulation/qemu if you want to try it out. Other facilities will be rolled out in future.

The RPi3's SoC has a hardware random number generator, added the sys-apps/rng-tools package to start using it for /dev/random.

Added the top-level package media-sound/mpd and media-sound/mpc (a music player daemon and client).

Added a service (rpi3-safecompositor) which turns off display compositing if a high pixel clock is detected (> 1.2175MHz, currently). This is because certain applications, for example LibreOffice v6 Draw and Impress, can cause the whole system to lock-up when used with compositing on under such conditions.

Added a startup service (rpi3-ethfix) to workaround some of the current RPi3B+ Ethernet issues via ethtool.

First tests - booting up and shutting down , it runs on both my Pi3B+'s and both 16GB Sandisk A1 cards.
Previous version had issues with one card and one Pi3B+
Also seems to shut down much faster.

No lockups yet on either Pi/SD combo
30+ minutes of testing each.
With both going, I can stress test them at the same time.
Perhaps time to get some more Pi3B+'s too as Kernel 4.14.44 seems to be much better.

Very happy with this 1.2.2 version.
Much, much better than precious version, well done Sakaki.
I am even using old mouse that does not work on other PC's

I have one Pi3B+ that consistently locks up.
I use the glxgears demo and the gears stop turning on lockup.
Locked up with
sdram_freq=500. arm_freq=1400
sdram_freq=450. arm_freq=1400
sdram_freq=400. arm_freq=1400

I've just posted a v1.2.2 release of my bootable 64-bit Gentoo image for the RPi3 (model B and B+) on GitHub (here, includes full download instructions).

A changelog from the prior release image (with upgrade instructions) may be viewed here, but in summary:

Migrated the default binary kernel package from bcmrpi3-kernel-bin to bcmrpi3-kernel-bis-bin; the latter uses a slightly tweaked version of the upstream bcmrpi3_defconfig via this weekly autobuild (to which, incidentally, config-change PRs will be accepted for review). The original bcmrpi3-kernel-bin package (and autobuild) will continue to be supported, and indeed you can easily switch to this version if you desire (just run, as root, "emerge -av1 sys-kernel/bcmrpi3-kernel-bin && reboot"). However, having the ability to tweak the configuration (and possibly kernel source in future) provides additional flexibility. For example, in this release KVM is supported (see this thread) and the image ships with app-emulation/qemu if you want to try it out. Other facilities will be rolled out in future.

The RPi3's SoC has a hardware random number generator, added the sys-apps/rng-tools package to start using it for /dev/random.

Added the top-level package media-sound/mpd and media-sound/mpc (a music player daemon and client).

Added a service (rpi3-safecompositor) which turns off display compositing if a high pixel clock is detected (> 1.2175MHz, currently). This is because certain applications, for example LibreOffice v6 Draw and Impress, can cause the whole system to lock-up when used with compositing on under such conditions.

Added a startup service (rpi3-ethfix) to workaround some of the current RPi3B+ Ethernet issues via ethtool.

A variant image for the Pi-Top v1 (an RPi3-based DIY laptop) is also included.

Have fun ^-^

And, as always, any problems or comments, please post either in this thread, or in the project's (sticky) thread on the Gentoo forums (here).

This is awesome, thanks, (and i regret not registering as nyamo now)
is anyone compiling on a higher powered machine and then sending their binaries to the Pi?
Just curious how people are compiling if this is how anyone is doing it. (or are you all compiling everything within the pi?)

is anyone compiling on a higher powered machine and then sending their binaries to the Pi?
Just curious how people are compiling if this is how anyone is doing it. (or are you all compiling everything within the pi?)

There is some info on the Gentoo Arm forums.
To me is seems like the hard stuff is cross compiled on PC's.
Things like the Kernel and Rust/Firefox etc.
Things that need 12GB of ram and 4GB swap files etc.

I am starting to do OpenGL stuff on Gentoo64, it is easier than Linux or Raspbian.
Mainly I think because Sakaki has included all the stuff needed in this distribution.
GCC and a lot of build tools are already there.

There is still lots of stuff not ported (ebuild) for aarch64 yet.
Run Porthole to see what is available, there is more than I thought.
Type in something and it will say if there is a build and it's dependencies.
emerge is the CLI version, it is similar to the sudo apt-get install xxx method in Raspbian.

Some things need lots of memory to compile on the Pi, Sakaki shows how to run headless, freeing up the GPU memory.
See the ARM Compute Library compile wiki.

This is awesome, thanks, (and i regret not registering as nyamo now)
is anyone compiling on a higher powered machine and then sending their binaries to the Pi?
Just curious how people are compiling if this is how anyone is doing it. (or are you all compiling everything within the pi?)

nes_pi (sensei? ^-^)

As Gavinmc42 states above, there are various ways to go about this.

Small or script-based packages will emerge (build) quite happily on the RPi3 natively (3B+ preferred), just make sure you have an appropriate heatsink fitted, and consider running with the GUI off (headless). I have my buildserver 3B+ in a Flirc case, which works well.

For larger packages that use gcc, you can distribute the compilation via distcc, using (most commonly) one or more PCs on the same network to perform the actual (cross-)compile (built using e.g. Gentoo's crossdev framework). I have full instructions for setting this up on the project's wiki (hereff). You can distribute clang this way too (see e.g. these notes).

For some packages, however, this trick won't work. For example, rustc won't distribute (or at least, not without some deep ledgerdemain) and is very resource hungry in terms of memory. And once the RPi starts seriously swapping, compile times go through the roof (building rust natively can take literally days to complete).

For these latter situtions, you can either compile on a more powerful arm64 box (for example, NeddySeagoon builds packages on a Clavium THUNDERX) or use a user-mode qemu chroot from a host PC. I build packages like firefox and rust using the latter approach and have full instructions for setting this up on the project's wiki, here. This isn't a magic bullet either though, as certain things (such as java) currently don't build correctly under qemu. So you have to mix and match. Once the binary pacakges are built, they are then uploaded (in the case of this project) to a shared binhost (https://isshoni.org/pi64pie) so all users can emerge them quickly on a standalone RPi3 without having to rebuild.