PoempelFox Blog

[..] [RSS Feed]
 

Sun, 14. Jul 2013


NTP-GPS-LED-Clock Created: 14.07.2013 10:53
Shortly after the NTP DCF77 LED Clock was finished, work began on a successor with GPS and a different network connection. However, this project never really progressed very fast. In the end it was only partially finished in 2012, mostly thanks to the support from Andreas Schwarz, after it had been lying around in a corner gathering dust for years.
Partially finished means that this is now actually hanging on the wall in the NOC at HaWo, where it usually displays the time, but a few problems/bugs remain.
For more information, head over to the NTP GPS LED clock project page.
You can leave your comments below.
no comments yet
write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3

Sat, 18. May 2013


KLM and Schiphol Airport - where incompetence complements incompetence Created: 18.05.2013 12:45
TLDNR: KLM sells/advertises trips with short 40 minute stopovers at their main european hub airport Amsterdam Schiphol. Avoid these. While in theory they have everything that is needed to make this work pretty reliably, they are too dumb to use the facilities they have, making it far more of a risky gamble than needed.

I recently had a flight from the UK (Glasgow) to Germany (Nuremberg), booked through the KLM website. Since the way KLMs network of flights is organised centers around their main european hub airport Shiphol in Amsterdam (Netherlands), it naturally involved a layover there. KLM claims that a 40 minute layover is enough for flights within europe (50 minutes for intercontinental flights), and the website will therefore suggest/sell tickets taking this into account.
When I first read that some time ago, I was a bit sceptical whether 40 minutes was enough, but the KLM website advertises this as practically the best invention since sliced bread. They also have these videos, e.g. the "easy transfer" video here, that show you how they intend to make it work: Your baggage gets transferred automatically of course, and passengers with short connections can use priority lanes at the passport control. So far for the theory, and I actually used this successfully before, but now have to conclude that I was just lucky it worked, because KLM and Schiphol will do nothing at all to make it work properly.
I was flying with two friends. Our flight itinerary said we would land in Amsterdam at 15:50, and our connecting flight would leave at 16:30. All times mentioned in the following come from my memory, so they may be slightly off - but you should get the general idea. While we were still in the air approaching Amsterdam, our pilot already told us (among lots of other things we could not understand due to his mumbling and the aircrafts noise) that we would be landing on the outermost runway, meaning that we would have to "taxi" for around 20 minutes before reaching the terminal. This is one of the problems of Shiphol, they have runways that are far far away from the actual airport facilities, so the plane just drives around on the ground for up to 20 minutes (not exaggerating!), going over a bridge over the highway and then driving between some canals in the process. This can be entertaining if you have the time, after all you're getting a free tour through half of Amsterdam, but in this case it was just annoying, and the first small source of delay: We arrived at our parking position at 15:55.
Unfortunately, we could not leave the plane then. According to a loudspeaker announcement, we had to wait for the hand-luggage that had been stored in the hold to be placed next to the exit. What a great idea to let all passengers that did not even have any hand-luggage stored in the hold and that have short connecting flights wait for another 5 minutes for absolutely nothing! And then we still had to transfer by bus.
Finally having reached the actual airport a few minutes past 16:00 and knowing we were now really really late, we hastily made our way through the airport. We were luckily able to pick up which gate we had to go to from one of the big monitors on our way, so we did not have to stop at one of the self-service terminals to get that information. And as expected, it was a gate (B28) at the completely opposite end of the airport, a walk of more than 20 minutes at normal walking speed. However, we're young and relatively healthy, and therefore walking pretty fast, although at that point we weren't running yet. We quickly reached passport-control, and this is where things really started to go downhill.
As explained in the nice "easy transfer" video, they have priority lanes for first class and short-connecting-flight-passengers. That's actually only half the truth: They have a sort of priority-priority-lane for short-connecting-flight-passengers that can jump right to the head of the queue in the priority lane. That however was closed off when we arrived, and the two incompetent idi... employees that are there to direct passengers to the right queue just directed us to the normal priority lane. Big mistake. Because the priority lane lead to just two open passport control stations, and both were apparently blocked by people leading lengthy discussions with the immigration officials. A big queue had built up already, and it was not moving the slightest bit. We quickly realized that the non-priority queue moved a lot faster than our priority queue, something that the two employees whose only job it is to direct people should also have noticed a long time ago. If they had not been that incompentent, they would have directed us to the non-priority queues instead, or better yet: They should have let us jump to the head of the non-priority queue. But even when we overheard other passengers complain about the non-moving priority lane, they just said they didn't know what to do, and ordered them to stay in the priority lane.
So we stood there, and spent minutes waiting for the queue to move again. When it finally did, the employees directing people then suddenly started to use the priority-priority-lane after all, and put people through that, meaning that people that had arrived 5 minutes later than us passed through passport control before us. After having wasted close to 10 minutes in the queue, we finally reached passport control and passed through it in just a few seconds, as is to be expected with European passports entering Schengen-Europe.
Behind the passport control was security. There was really nothing to complain about here - there was no queue at all, and I was through in no time at all. My two friends needed slightly longer, one had to take off his hiking shoes because they thought the metal inserts would confuse the metal detector, the other had to show what was inside her backpack, but all in all there was no significant delay here - we were through in less than 5 minutes.
After security we could see on the monitors that our flight was by now listed as "gate closing" and continued to sprint.
Shortly afterwards we heard the infamous announcement that you hear in Shiphol all the time: "Passengers (absolutely indecipherable mispronounciation of our names) travelling to Nuremberg, you are delaying the flight. Immediate boarding please at gate B28, or we will proceed to offload your baggage." - after this we started running as fast as we could, and finally reached the gate less than 5 minutes later - it was now almost 16:25, so in theory 5 minutes before the scheduled departure, but too late nonetheless, as the gate usually closes 10 minutes before departure time. So in other words, just to spell that out: when they sell you a 40 minute layover, in reality it always is just a 30 minute layover.
As expected, we were told at the gate that we were too late and that they were in the process of unloading our baggage. This is actually what I consider another display of major incompetence: As we were not boarding, they had to remove our luggage from the hold, meaning searching through all of the luggage in the hold and removing our three bags. This takes a few minutes. If they had simply cancelled that process as we arrived, and let us board, they would actually have delayed the flight LESS, because us boarding would surely have been faster than continuing to search the hold for our three bags. But their thinking clearly is "fuck passengers".
We were then told that there was another flight to Nuremberg later that day, and that we should simply rebook at the transfer desk T2 in the main hall. If the attendant at the gate was lying on purpose to quickly get rid of us or just did not know due to KLMs complete lack of organisation is unknown, but as we found out at the transfer desk a bit later, that flight was full. As were all other flights to Nuremberg in the next two days. I simply was put on the waiting list with the comment that I would almost certainly get a seat, without being offered any alternatives. My two friends got handled a bit better, and took the option of taking a flight to Munich instead of spending possibly multiple days on the waiting list, having to stay in the airport all the time. There is good train connectivity from Munich to Nuremberg, so this was not a bad alternative, although KLM refused to pay for the train ticket.
This is another thing that pissed me off: KLM denied any responsibility for the missed connection. I overheard them saying "It's not our fault, it's the airport facilities" to another couple who had missed their connection. Well, I'm sorry, but that excuse just is not valid. First and most importantly: You, not any third party but YOU KLM, did sell me the tickets for this very short connection, so it is your responsibility to try everything to make it work. That could have included just letting us board when it was still technically possible when we arrived late clearly not due to our own fault. As I already explained, it probably wouldn't even have caused any delay. More generally speaking, it could also include giving passengers another five minutes to make it to boarding when you know that the incoming flight was late, IF that will not delay the flight. You might think that waiting for late passengers would always delay the flight, but that is not true: It happens in Shiphol (and in fact it did happen to me on that same day), that even after boarding is complete, the plane will just stay at the gate for another ten minutes, because there is so much congestion on the runways that it cannot start anyways. In this case there is absolutely no need to hurry the boarding, but they still do.
So, since you failed to do anything at all to make me catch my connection, you should at least have moved your lazy ass after the missed flight. Of course, you cannot just throw passengers off a later flight to make room for me, but offering alternatives to "sit in the terminal for 5 hours hoping you get a seat through the waiting list" would have been the least. As would have been a food and phone-home-on-KLMs-expense voucher.

I actually did get a seat on the later plane to Nuremberg, but I'm not sure what would have happened if I had not - I doubt KLM would have paid for a hotel room for me without major discussion, if at all. My two friends flew to Munich, and paid for their own train tickets from there to Nuremberg. If they had also taken the waiting list offer, two of us would have had to stay in Amsterdam over night - the plane I was on was completely full.

To wrap up this post, I have this related picture below: It shows one of the KLM self service checkin terminals at Glasgow airport.

These nice error messages kept popping up on all their self service terminals, whether someone was currently using them or not. In general, KLM seem to be real "experts" at running their computer systems... The online-checkin on their homepage frequently throws nonsense-error-messages as well.
no comments yet
write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3

Wed, 06. Mar 2013


Intel MIC/Xeon Phi MPSS on Ubuntu Created: 06.03.2013 20:39
I recently tried to get the Intel Xeon Phi Software Stack (Manycore Platform Software Stack, MPSS) to run under Ubuntu 12.04. More exactly, the version KNC_gold_update_1-2.1.4982. Ubuntu is not supported (yet), but it did not prove to be too difficult. As Google wasn't exactly helpful with setting this up, I'm writing this blog post in the hope that others googling for "mpss ubuntu" will find it and it will be helpful for them. Note that this is not a complete HowTo though, but it should help you get going. Use at your own risk.
  1. The first step is to download KNC_gold_update_1-2.1.4982-15-suse-11.2.tgz, i.e. the version for SLES11 SP2 offered on Intels download pages.
  2. Unpack the tgz, and inside you will find some RPMs and a bunch of subdirectories. The RPMs are the important part here: Convert them all with "alien --scripts", except intel-mic-kmod-2.1.4982-15.3.0.13.0.suse.x86_64.rpm which contains the kernel modules that would be surprisingly unhelpful on an Ubuntu kernel.
  3. The kernel modules will have to be rebuilt for the Ubuntu kernel from source, and their source will have to be patched as they're not compatible with the 3.2 kernel in Ubuntu 12.04. There is more than one way to do this, I choose to use the provided spec-file and then convert the resulting RPM. The source of the kernel modules is hidden in src/intel-mic-kmod-2.1.4982-15.suse.src.rpm. Unpack that with rpm2cpio src/intel-mic-kmod-2.1.4982-15.suse.src.rpm | cpio -idmv and you get a spec file and a .tar.bz2. You need to put these two files and the patchfile intel-mic-mpss21up1-kmod-2.1.4982.patch into your rpmbuild SOURCES/SPECS directory. The spec-file needs to be patched with intel-mic-mpss21up1-kmodspecfile.patch, after that you can run rpmbuild -bb intel-mic-kmod.spec. The result of this will be an intel-mic-kmod-2.1.4982-15.3.2.0.38.rpm.x86_64.rpm, which you need to convert with "alien" again into a intel-mic-kmod_2.1.4982-16.3_amd64.deb.
  4. Install the kernel module .deb together with the .debs you converted in step 1.
  5. micctrl and the other tools put their libraries into /usr/lib64, which does not normally exist anymore in Ubuntu 12.04, thus the linker is not searching for libraries there. You need to echo "/usr/lib64/" > /etc/ld.so.conf.d/mic.conf and then run ldconfig to fix that.
  6. By now you should be able to execute micctrl without major error messages, but you cannot really do much, because mpssd needs to be running for the card to actually do anything.
  7. The init-script for mpssd needs to be adapted so it actually starts the mpssd. I cannot post my patch for the initscript, as it contains quite a lot of messy workarounds tailored to our system. However, to actually get the script to work, you only need to fix one thing: Just replace the line that reads startproc -t 1 $exec with these two:
    [ -d "/var/lock/subsys" ] || mkdir /var/lock/subsys
    start-stop-daemon --start --exec $exec
    After this the script will still print A LOT of error messages about all the missing rc_* stuff, but it will actually start and stop the mpssd daemon now.
  8. Normally, the configuration of the virtual micN network-interfaces would happen automatically, but as the Intel stack knows nothing about the "Debian/Ubuntu way of things", it cannot do that. You will need to manually edit /etc/network/interfaces and give them a proper configuration. In the default network config, the card gets the IP 172.31.1.1 and no bridging, so a proper entry in /etc/network/interfaces would look something like this:
    iface mic0 inet static
      address 172.31.1.254
      netmask 255.255.255.0

So that's it, you can now start to play around with the card. Which is not always an easy task.
For example, it seems MPSS has never heard of these fancy things like "directory services" where you do not create all users locally on all of your computers, but in a central directory instead. This is probably because Intel is such a small company that they only have 2 or 3 computers, so this isn't relevant for them.
But I will leave my ranting about the immatureness of the system software stack for an otherwise nice product sold at a quite significant price tag (ca. 2500 Euros) for another time.
6 comments
Hi,

As things are evolving quickly, I was wondering if you have you tried to install MPSS3.1 with Ubuntu12.04.03LTS? If so, ;-) could you help me out.

Thanks in advance.
Jofre
Jofre 31.10.2013 12:40

I have not, at least not yet.
PoempelFox 31.10.2013 19:25

You can download a patch for MPSS 3.1.2 kernel module. mic.ko, from here:

http://software.intel.com/sites/default/files/mpss_mod_patch.txt

Copy it into mpss-modules-3.1.2 source directory and apply:

patch -p1 < mpss_mod_patch.txt
Alexei 11.02.2014 19:27

Hi,
I am trying to install MPSS3.1.4 with Ubuntu 12.04.1. I am following your instructions and adapting when it is neccesary. For the moment it does not run, but I hope it will be able to run soon.
If you can help me for the last steps I will be very glad.
Did you try this installation ? May you help me ?
Thanks.
Virginie
Vivi 11.03.2014 13:37

Hi !
I need to install Xeon Phi, but my motherboard is not compatible. I will buy a new one, but I want to be sure of my choice.
Could you tell me which one you are using for Xeon Phi ?
Thanks in advance.
Virginie 14.03.2014 10:44

ASUS P9X79W works NOT the P9X79L.

Specifications about PCI interface are criticals.



AloMoi 20.04.2016 08:19

write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3

Sun, 03. Mar 2013


Fake traceroute Created: 03.03.2013 20:38
About a month ago, the Star Wars Traceroute circled the Internet. I found it quite amusing - and thought that I could improve on that idea.
My first experiments to generate something similar with stock Linux kernel tools (like ip6tables and different routing tables) were pretty unsuccesful - something was always missing to make it work properly. There also is a perl utility called countertrace which does something similar, but it did not have all the features I wanted and AFAIK does not support IPV6. So in the end I simply coded a small program that would listen on a network interface and send hand-generated packets back to fake the hops in the traceroute. This actually made some things a lot easier to implement: The trace can contain hops that depend on the current time or on the temperature. This would have required constantly changing the rules if I had done it with stock kernel tools, but the way it's implemented now the program just has to adapt the (fake) IP in the reply. Another nice feature that was easier to implement was that you can set the delay for every hop - so you can properly fake e.g. the delay a transatlantic hop causes.
You can see all this in action by doing an IPv6 traceroute to target.fauad.de (2001:470:1f0b:1d0f:23::ff). I do not think it's a good idea to use completely bogus hostnames, possibly hitting domains belonging to someone else in one of the 10 trillion new TLDs, which is why all my hops have an added .fauad.de; and I do not think it's a good idea to use too long quotes from movies for copyright reasons, so in this respect, my traceroute is less cool. But it allows you to get the current time and temperature in Germany, which is the killer-feature you always wanted, isn't it?
So here is how the traceroute currently (at half past 8 on the 3rd of March 2013 with a temperature of about -3 degrees outside) looks like:

# traceroute -6 -m 100 target.fauad.de traceroute to target.fauad.de (2001:470:1f0b:1d0f:23::ff), 100 hops max, 40 byte packets using UDP [...] 8 tserv1.fra1.he.net (2001:470:0:69::2) 17.614 ms 17.032 ms 18.992 ms 9 you.have.reached.germany.fauad.de (2001:470:1f0b:1d0f:23::1) 21.104 ms 22.468 ms 19.845 ms 10 local.time.is.20.32.fauad.de (2001:470:1f0b:1d0f:1:2032:0:1) 20.834 ms 19.981 ms 20.121 ms 11 and.the.current.temperature.in.Erlangen.fauad.de (2001:470:1f0b:1d0f:23::3) 19.884 ms 19.846 ms 20.476 ms 12 is.minus-2.95.degrees.celsius.fauad.de (2001:470:1f0b:1d0f:2::5705) 20.202 ms 19.860 ms 20.234 ms 13 im.not.crazy.fauad.de (2001:470:1f0b:1d0f:23::5) 20.094 ms 19.909 ms 19.820 ms 14 my.mother.had.me.tested.fauad.de (2001:470:1f0b:1d0f:23::6) 20.458 ms 19.768 ms 19.680 ms 15 and.at.least.im.not.wasting.ipv4.for.this.fauad.de (2001:470:1f0b:1d0f:23::7) 20.651 ms 20.708 ms 20.127 ms 16 Oo.oO---------------------------------Oo.oOo.fauad.de (2001:470:1f0b:1d0f:23::20) 20.340 ms 19.857 ms 20.024 ms 17 so.lets.see.where.this.is.going.fauad.de (2001:470:1f0b:1d0f:23::8) 20.141 ms 20.004 ms 19.817 ms 18 40ge-7-3.fra1.de.fauad.de (2001:470:1f0b:1d0f:23::9) 20.382 ms 20.890 ms 20.202 ms 19 invasive.pat.down.tsa.security.theater.us.fauad.de (2001:470:1f0b:1d0f:23::a) 99.836 ms 98.758 ms 98.147 ms 20 no.such.agency.spycorps23241.us.fauad.de (2001:470:1f0b:1d0f:23::b) 110.627 ms 110.739 ms 110.602 ms 21 40ge-1-2.ny1.us.fauad.de (2001:470:1f0b:1d0f:23::c) 112.935 ms 111.858 ms 111.163 ms 22 no.such.agency.spycorps812424.us.fauad.de (2001:470:1f0b:1d0f:23::d) 119.413 ms 118.728 ms 117.650 ms 23 28kbit-3-2.funafuti1.tv.fauad.de (2001:470:1f0b:1d0f:23::e) 206.467 ms 205.527 ms 204.449 ms 24 10ge-4-1.beijing.cn.fauad.de (2001:470:1f0b:1d0f:23::f) 232.709 ms 232.126 ms 231.047 ms 25 40ge-5-9.erl1.de.fauad.de (2001:470:1f0b:1d0f:23::10) 290.281 ms 299.625 ms 298.543 ms 26 it.seems.this.was.the.shortest.path.fauad.de (2001:470:1f0b:1d0f:23::11) 297.446 ms 296.811 ms 295.727 ms 27 Oo.oO---------------------------------Oo.oOo.fauad.de (2001:470:1f0b:1d0f:23::20) 291.313 ms 290.374 ms 299.368 ms 28 our.whole.universe.was.in.a.hot.dense.state.fauad.de (2001:470:1f0b:1d0f:23::12) 298.633 ms 297.558 ms 296.479 ms 29 then.nearly.fourteen.billion.years.ago.fauad.de (2001:470:1f0b:1d0f:23::13) 299.223 ms 298.138 ms 297.057 ms 30 expansion.started.WAIT111.fauad.de (2001:470:1f0b:1d0f:23::14) 299.245 ms 298.163 ms 297.076 ms 31 im.afraid.this.will.have.to.stop.here.fauad.de (2001:470:1f0b:1d0f:23::15) 292.238 ms 291.157 ms 299.893 ms 32 to.avoid.nasty.copyright.infringement.letters.fauad.de (2001:470:1f0b:1d0f:23::16) 298.907 ms 297.829 ms 296.745 ms 33 so.thats.it.for.now.fauad.de (2001:470:1f0b:1d0f:23::fd) 289.845 ms 299.042 ms 297.962 ms 34 ill.be.back.fauad.de (2001:470:1f0b:1d0f:23::fe) 296.882 ms 295.801 ms 294.715 ms 35 you.have.reached.your.destination.fauad.de (2001:470:1f0b:1d0f:23::ff) 299.357 ms 298.276 ms 297.195 ms

I'll probably release the sourcecode of this in a few weeks when I'm done playing with it.
4 comments
Hi,
i have a (maybe very silly) question.
Why is on your traceroute after tserv1.fra1.he.net your /48 HE-Net IP and not the HE "Client IPv6 Address" ?

btw: it would be great if you would publish the source
meinname 16.03.2013 01:39

Remember that everything you see is completely fake. Of course the next real hop after the HE tunnel server is the client IPv6 address, but there is no reason for you to see it: Your traceroute packets are addressed to an IP in the /48, and it is an IP the machine does not have configured on a kernel level, so the kernel will not send a reply on its own.
PoempelFox 16.03.2013 23:49

Ahh, thnx for the explaination.
meinname 17.03.2013 00:35

Hi,
do you still plan to release the sourcecode?
meinname 07.06.2013 17:46

write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3
 

EOPage - generated with blosxom