IPv6, BGP, Elevators, MaxIOPS, Threading, Hobbies, Creepy Data, E-residency, uWSGI

Post date: Dec 7, 2014 6:35:34 PM

  • IPv6 adoption globally is now at 5%. Information from Google IPv6 global adoption statistics site. https://www.google.com/intl/en/ipv6/statistics.html Belgium leads with 28% adoption rate.
  • Studied new image (compression) format BPG, which looks really good, even better than WebP. The question is only that is it partially patented or not. I've been personally very disappointed how slowly (if at all) things like JPEG 2000 (.JP2) and JPEG XR (.JXR) have been adopted, even if those provide advantage over older formats.
  • Latency changed between my servers (in datacenter) and home, now latency is about 1,3 ms when it was about year ago only 0,9 ms. That's horrible ping!
  • Multi is new(?) elevator concept where there could be multiple elevators in same shaft. But personally I find it funny that it hasn't been introduced a lot earlier. As well as their current design is bad, because the one shaft is still blocking traffic when elevators stop. I would prefer option where there are let's say six shafts, and only some of those got doors. So cars which are stopping won't block other traffic. Just like taxis operate at airport drop off / pickup points. When this is computer controlled it's much faster and safer than with cars. Six shafts could allow operating tens of elevator cars in same space. As well as some floors like ground floor could have six doors, and other floors usually two, leaving shafts free for passing stopped cars.
  • Played a little with UpCloud's new MaxIOPS, which providers better than SSD IOPS performance on the cloud.
  • Nice post: Make Your Program Slower With Threads. Nothing new there. As my database tests showed earlier, context changes and locking can really kill the performance. That's why I prefer 'shared nothing model' and if that's not possible, then communicating between threads using only locking queues and proper "chunk size" so the inner loop doesn't pop stuff from queue one at time, but instead takes anything between 100 to 1M entries depending from situation, so the locking doesn't start to dominate the process. Yet, it's interesting to see, how people (all people) hit the same performance, synchronization, and so on, problems over and over again.
  • The hobby project we've been working on during weekends with my friends, currently uses threads very sparingly. We prefer fully asynchronous message queues and just a few threads instead of launching a large number of threads for processing data from multiple sources. Current design has worked very well, and performs well and it's memory and CPU friendly too. Basically there are just three threads + a few workers. Inbound message handler, Outbound message handler, Controller thread and number of CPU cores workers as processes due to CPython GIL limitations.
    • The project also uses the old tricks I've been using earlier. Basically tapping into existing program code with minimal modifications. I'll just launch my own parasite thread inside the main program and then add a few asynchronous queue calls where ever is required for I/O operations. Some times I also directly call the main programs methods or create my own instances of objects available in main program. What ever is required to get to the goal with minimal work. It's not always beautiful, but is easy and a dirty way to plug into systems which do not provide proper plug-in / integration features requiring minimal amount of work.
  • It seems that Finland is going to get a lot better Internet connectivity toward central Europe by Cinia Group new Operation Sea Lion.
  • When data gets creepy. - I have nothing to add, this shouldn't be news to anyone. Everything you do is being monitored, stored, archived, indexed and analyzed.
  • E-residency got launched on 1.12.2014. Now you can access digital signing to on-line business registration and backing.
  • Still wondering why I just can't get my uWSGI to listen on IPv6 interface. Even if everything is just fine with the LXC container where I'm running it. If I just start listening for connections using Python 3 sockets there's no problem with IPv6 what so ever. uWSGI documentation didn't shine any light into this matter. I guess I'll have to post a Stack Overflow question.