September 20, 2019, 06:29:51 am

News:

Have you visited the Allwinner Chipset wiki? - http://linux-sunxi.org/


cubietruck NIC corrupting data?

Started by foef, May 25, 2014, 08:20:14 am

Previous topic - Next topic

greentown

Hi,

I've just done a quick test and removing the overclocking has solved my scp issues.

I have been overclocking x86 CPUs for a long time and I can say that 20% is not something that you can normally and easily get away with. It depends on the processor, and, above all, on luck. Being a SoC solution, I can only imagine that overclock margins are even slimmer than on general purpose CPUs.

Bottom line. It seems like we found the culprit!

foef

I will try the modification most probably today and report later.

Quote from: greentown on June 30, 2014, 06:08:04 pmI've just done a quick test and removing the overclocking has solved my scp issues.


So you got the same error that I reported? Because in the whole thread there was never anyone reporting that he/she could reproduce the faulty data transfer...

greentown

Hi foef,

I think I had the same issues. I posted about it here: http://www.cubieforums.com/index.php/topic,1275.msg17874.html#msg17874

And yes, before, I could reproduce the problem consistently. Previously, I could not transfer more than 500MB without the corrupted MAC error, but yesterday I transferred 8GB without a problem. If I have time, I will try to do some more tests today.

Sloop

July 01, 2014, 07:08:14 am #33 Last Edit: July 01, 2014, 05:45:35 pm by Sloop
I had the same issues as explained on slovenia's image thread HERE and HERE. After slovenia pointed me to this thread I red through and saw the comment about cpu-overclocking. So I tried out and modified the /etc/init.d/cpufrequtils file and changed line 44 from pre-defined value "MAX_SPEED=1200000" to the suggested nonoverlocking value "MAX_SPEED=960000"

After that I restarted that service by command "/etc/init.d/cpufrequtils restart" and started the BackupPC command which is using rsync for the backup transfer.

Actually it's running over 16mins now without any crash and that's looking awesome good. I hope the process will finish without any errors. In former times the process crashed after 500-800MBytes transferred and after a very short period. I think we found the culprit and it looks like my Cubie is working fine now. I will post again when the whole BackupPC process is finished. I am backing up a host with 1TB of data so this will delay :)

Thanks so far. Cheers, Sloop.

Update: over 11 hours elapsed and still running ... looks good :D In summary I would say, we have found the culprit.

rose28357

I cross my fingers !!!!

If it is a stability problem the better Voltages and timings may help.....

foef

Just finished testing with fresh copy of CTDebian 2.2. Modified the cpu freq max. Besides only modified network settings and fstab.

uname -a
Linux cubie 3.4.94-sun7i+ #1 SMP PREEMPT Tue Jun 24 11:08:42 CEST 2014 armv7l GNU/Linux


Result:
sent 409040 bytes  received 101542649104 bytes  7308147.69 bytes/sec

NO CORRUPTION

foef

Just noticed a new version of CTDebian by Igor Pecovnik has been released including the fix that solved the original trouble of this thread. (version 2.3)

http://www.igorpecovnik.com/2013/12/24/cubietruck-debian-wheezy-sd-card-image/

Thanks to everyone and finally I can focus on setting up my cubie server and replacing my old 50+Watt monster.

almochris

So just to be clear:

Was your problem caused by overclocking or was it the voltage parameters in script.bin being slightly off for your board?

I am wondering if the best practice is to use the voltage params posted by slovenia in the post http://www.cubieforums.com/index.php/topic,2590.msg17824.html#msg17824

foef

Quote from: almochris on July 03, 2014, 06:32:20 am
So just to be clear:

Was your problem caused by overclocking or was it the voltage parameters in script.bin being slightly off for your board?

I am wondering if the best practice is to use the voltage params posted by slovenia in the post http://www.cubieforums.com/index.php/topic,2590.msg17824.html#msg17824


... good question. I don't know. Can anyone else chip in and clarify?

slovenia

Quote from: foef on July 03, 2014, 07:39:21 pm
Quote from: almochris on July 03, 2014, 06:32:20 am
So just to be clear:

Was your problem caused by overclocking or was it the voltage parameters in script.bin being slightly off for your board?

I am wondering if the best practice is to use the voltage params posted by slovenia in the post http://www.cubieforums.com/index.php/topic,2590.msg17824.html#msg17824


... good question. I don't know. Can anyone else chip in and clarify?


My default voltage parameters weren't changed since this patch, actually I am using them since v1.0:
https://www.mail-archive.com/[email]linux-sunxi@googlegroups.com[/email]/msg04662.html
They supposed to be better than factory defaults.

It looks like the NIC corruption was caused by over clocking  :-[ It simply went out of my focus.  :-X To be absolutely sure about it we need more tests. Best with latest image and it's default settings.
Debian and Ubuntu images with kernel 3.4.110, 4.3.3, 4.4
http://www.armbian.com

foef

July 05, 2014, 09:59:57 am #40 Last Edit: July 05, 2014, 11:01:39 am by foef
Quote from: slovenia on July 04, 2014, 01:46:51 am
To be absolutely sure about it we need more tests. Best with latest image and it's default settings.


I'm running the 2.3 image with default settings. Just setup a bash script to copy my 100GB of data 10 times. I will report later when finished (~39 hours at 7 MB/s).

Sloop

it would be nice if anyone could investigate some more tests while slightly raise the overclocking to acceptable values. So we know how much overclocking is allowed without leading the cubietruck to crash.

-sent from my Raspberry Smartphone-


patap

It looks like it's better to not overclock at all. What is the use case that needs few % more performance?

Some talk about allwinner soc stability

https://groups.google.com/forum/#!topic/linux-sunxi/h28gFGvYflc

Plotted soc behavior clock/voltage minimum

http://people.freedesktop.org/~siamashka/files/20140512/sunxi-cpufreq-plot.png

ssvb

Quote from: Sloop on July 06, 2014, 08:29:49 am
it would be nice if anyone could investigate some more tests while slightly raise the overclocking to acceptable values. So we know how much overclocking is allowed without leading the cubietruck to crash.

As mentioned earlier in this thread, pretty much every Allwinner A10 chip fails the cpufreq-ljt-stress-test at the clock speeds higher than 1.1GHz - https://www.mail-archive.com/[email]linux-sunxi@googlegroups.com[/email]/msg05843.html
Also confirmed by the results from lioka - http://irclog.whitequark.org/linux-sunxi/2014-07-03#9501794;

And this is only a single test program, which is not necessarily the most demanding. So having some CPU clock speed safety margin is a good idea. The default choice of 1GHz is very much reasonable. Allwinner A20 has even lower default clock speed than Allwinner A10. Neither of them can be clocked at 1.2GHz reliably.

The Chinese sellers from AliExpress did a lot of damage mis-advertising the unrealistic 1.2GHz and even 1.5GHz clock speeds for Allwinner devices. So people may feel encouraged to try these higher speeds and hurt themselves, just like we could see in this thread.

foef