New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
@rm_ Yeah but the network 'mvneta' card still relies on DMA which relies on CPU time. Therefore, the more load on your CPU that is assigned the IRQ, the slower throughput you will see on the network device because of the time it takes to process DMA requests when the CPU is busy. This is my understanding at least, and seems to have an effect in practice. Granted, the effect it likely much less than what would be see if you were using the options on smaller boards, but I did see some difference when CPU 1 load was high where network transfers would drop off. By setting affinity to CPU 2 (which was not as utilized) network speed increased again.
As I said, if you can find some documentation which states what I am doing completely useless, then I am more than happy to step back, learn something new and admit I am wrong.
Cheers!
DMA itself doesn't: https://en.wikipedia.org/wiki/Direct_memory_access
But sure, there's a lot of work to do aside from the actual data transfer, that still needs the CPU.
I was more so reading something like this:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0228a/index.html
As many of the arm boards do not have onboard cache for DMA, they share memory with the system and require more CPU time. Now, from what I was reading, there are some arm boards that do have a cache, is the one Online is using one of them? I don't know. I am looking for the technical details for ARM not just a generic explanation of DMA from wikipedia, but thanks.
Cheers!
256KB L2 cache: http://www.cnx-software.com/2014/06/13/marvell-armada-370-processor-datasheet-released-mainline-linux-kernel-supported-on-netgear-readynas-102104/
Also read http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-datasheet.pdf
a lot of interesting and highly-advanced stuff in there, even some sort of crypto acceleration, I wonder if it's possible to activate that for VPN and HTTPS...
Ahh, now we get to the information I was really after. Thanks for finding those, I will gladly review them. I will also do some more testing my self to get a better idea of what effect, if any true effect, setting the smp_affinity has for network. I really need to load up a few cores all the way and change it to see what effect there is if any. I will yield that for now I truly don't have a definitive test to say one way or the other, other than the short tests I have done showing positive results. I do know that these setting for sure have a large impact on the smaller boards, but without reading the whitepapers for these Marvel boards, I can't be sure what effect it truly has.
Cheers!
Keep posting all the little tweaks, it's nice to apply them even if it mostly idles
Are you going to see additional locations or it will be just France?
No 64bit
These aren't from the 370 line processors, they are from the Armada XP line. They are probably the MV78460 model and should have 2MB L2 cache. I can't verify this by know but I'm pretty sure that I am right.
Yeah this one then:
http://www.marvell.com/embedded-processors/armada-xp/
http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78460_OS.PDF
You already said it, in 2014, here: http://www.lowendtalk.com/discussion/comment/762683/#Comment_762683
Sure, I don't remember everything I posted. And I don't use any of these servers at the moment to constantly keep in mind what they have.
This is very good value for money. IMO, the kidechire 2 Eur a month server is better in the sense it has local storage and is x86, but that was very probably a one-off thing, these provide better cpu while having lower bw, non-local storage, being ARM, fixed kernels and 50% more expensive, but they should run almost everything the x86 ones do (except Windows joodle's images...) and should be available all the time, so... great way to get your hands dirty with an ARM without buying hardware that gets obsolete fast and you need to power and give a connection most of the time too.
My conclusion: definitely worth it, but I would get another kidechire instead if I could and needed.
They don't provide CentOS...
On the contrary these have higher b/w, 200 Mbit "guaranteed" vs 100 Mbit (as we learned) at Kidechire.
Is it possible to "burst" to 1Gbs with Scaleway for some time as it seems to be with the kidechire - or it the upload capped to 200Mbs?
Of course it is possible. It is not capped. Test the speeds for yourself at http://instantcloud.io/
I am not sure about that, or it does not work on my KD. I was able to do a lot of bursting, at least when I run tests in the beginning. Perhaps it works better on scaleway, I haven't done yet any tests on it, just came back from vacation, maybe I will soon.
What "it" does not work? Depending on neighbour's usage you get to burst to full gigabit both on Kidechire and on Scaleway, this hasn't changed. If you're going to reply with something similarly nondescript such as "but I cant", at least provide details on how exactly do you test.
I can achieve the same Tor-throughput on these with ~25% vs 100% CPU-usage on the kidéchire.
OT, but what's the burst threshold/period for the Kidechire boxes? A few hours of reddit/big-community traffic shouldn't be a problem , I hope.
Anyone receive a warning for regular web traffic, and not a tor relay?
...translation: with exactly one of the four cores used 100%.
Yup, Tor-power is all a cheap box needs.
Could you phrase that in MByte/s? Kidechire with or without padlock support?
I guess ~300mbps throughput should be possible.
O_O on a kidechire? ... Tell me more :0 As far as I remember I only got 50 mbit/s duplex (without padlock because no clue how centos works and don't want to patch)
Nono, on one of those ARM boxes.
I highly doubt it.
Maybe my assumptions aren't that accurate, but they come close.
Tor is using ~25% cpu while transfering ~55mbps, so in theory it could handle 220mbps:
That is only if (A) Tor multi-core support is massively improved, which is known to be difficult and should not be expected in the near future, or (B) you run 4 instances of Tor. And you cannot do (B), because the Tor network only accepts 2 instances at most, per IPv4 address.
Oh and also that's not "55 Mbps" at your screenshot, that's merely 28, when talking Tor b/w people don't sum in+out together, personally I'd say "28+28" in this case, for complete clarity.