Hi Karl
On 17.08.2017 15:13, Karl Palsson wrote:
It certainly _looks_ better, but isn't actually syncing...
Sincerely,
Karl Palsson
# /usr/sbin/ntpd -d -n -N -l -S /usr/sbin/ntpd-hotplug -p 0.lede.pool.ntp.org
-p working.good.org
ntpd: bad address '0.lede.pool.ntp.org'
ntpd: sending query t
Bjørn Mork wrote:
> This looks yucky. Experimenting a bit, I see that the result
> with
>
> a) -T 0 depends on multi-core vs single-core
> b) -T 1 is always different from the output of -T x where x > 1
> c) -T x where x > 1 is independent of both x and the actual number of
> cores
>
>
This looks yucky. Experimenting a bit, I see that the result with
a) -T 0 depends on multi-core vs single-core
b) -T 1 is always different from the output of -T x where x > 1
c) -T x where x > 1 is independent of both x and the actual number of
cores
So you will not get reproducible resul
On 18-08-17, Karl Palsson wrote:
> > This means that the archive will have a different checksum, and
> > thus affects reproducability. [1] suggests this is because of a
> > different block size default, but unfortunately there seems to
> > be no way to set the block size in an attempt to make it us
Jonas Gorski wrote:
> >
> > Previously: (xz -7e)
> > real3m13.631s
> >
> > Now: (xz -T 0 -7e)
> > real1m23.051s
>
> After playing around with it, it seems enabling multiple
> threads makes it compress slightly worse, at least in case of
> the linux kernel sources (86.8 MiB single thread
Hi,
On 17 August 2017 at 15:05, Karl Palsson wrote:
> xz has supported multithreaded compression since 5.2 in 2014. Enable
> it's automatic support for this via the "-T 0" flag.
its ;p
>
> Previously: (xz -7e)
> real3m13.631s
>
> Now: (xz -T 0 -7e)
> real1m23.051s
After playing around
This is a bugfix release
Build and run-tested on cns3xxx, imx6
Please note that starting from GCC 6.4.0 release, the bz2 flavor is not
available anymore, so the switch to xz is made for this target.
Signed-off-by: Koen Vandeputte
---
toolchain/gcc/Config.version | 2 +-
