izard

Here is my take after couple of months of playing with VR:
Vive, Oculus at al are cool, but they moved VR to a wrong direction. There should be no feedback from headset movements, just like it was in VR from 90s. The problem should be solved not from a technical setup perspective as now with sensors, but from bio-medical perspective, e.g. using a drug that temporarily weakens some links to cerebellum. So one can lie wearing a headset, and experience all kinds of movements in an open world. The only physical feedback loop that is absolutely necessary is eye tracking.

Always on and connected mobile experience:

1. Free app utilizing NFC to open doors/turn on/turn off engine of a car. When app becomes popular, push an upgrade which records acceleration after car engine is on and roughly calculates the speed. When speed is grossly over limit, calls police or better automatically transfers fine using online banking.

2. When you bring a broken phone to service center, they check a log of an app which uses accelerometer to record all free falls, and if there were any void the warranty.

Last one with black humor under cut.
( Read more... )

I am slowly working on an idea. Doing social auto-tune killer. My brother who is in music industry explained me that I did not invent anything special, you can buy a s/w like that starting from 250$.

I produce very messy code usually so have to use anything that helps to make it tidier. That is why using clojure:
( Read more... )
This is not final code of course, but at least it looks maintainable. If I was writing in Java or C++ that would have been a very bad mess.

Just posted a short article on habr. All in Russian.

Airplane flight recorder, an orange device, is now based on SSD AFAIK. Previously it was using magnetic storage.

When flying with Emirates today I've noticed they have a pico-BTS on board, which is apparently using a satellite uplink. To implement more or less real time GSM signaling uplink must be always online. So what is preventing from using the same link to save flight data to a remote location that is more secure then a device that some times can hardly be found?

P.s.just got back home, trip report from Seychelles is coming soon. Will have just to read/scan through around a thousand e-mails.
Today's sunrise on Victoria/Mahe airfield:

It's been one and a half years since I first decided I will implement a personal cloud solution. Six months ago, I realized how to make it secure for a service provider side. That was the biggest technical issue I needed to resolve to make it fly.

It was always difficult to find time to work on it, because there are always important work related projects that obviously had a priority. So I cheated: I've registered this project as a demo for an internal conference. This gave me an opportunity to use company's h/w to work on it, but 90% of the coding I had to do in my free time any way. However, a clear deadline (this Monday) helped a lot in motivating me. I managed to finish coding of a prototype which I can show to wider audience few days before the show :)

The demo was a success: it was selected as 3rd out of 40 projects. It was the only one out of top 20 that was done by single person as an unofficial project. Now thanks to feedback I got on this conference in Portland (I am writing this from PDX on the way home now) I have a clear picture about technical and marketing opportunities for AdHoC.

It is skunksworks project which is not really related to my job so I think it's safe to post about it before I get a formal approval to make it open source. (If I don't have the approval and someone will do something similar and open source I'll be happy too.)

AdHoC is an service to enhance user experience on Small Form Factor(SFF) devices. It allows _secure_ remote execution of any application on a "close" x86 box, redirecting a screen and input to SFF device.

I call it cloud because it can satisfy 4 out of 5 clauses of formal NIST cloud definition. It is PaaS variation.

Here is a technical description for those who might be interested:
( Read more... )

struct sk_buff is quite big (for a reason), 4 cache lines.

The way it's being accessed in a fast path (in reverse order), when system is running a network throughput benchmark fools h/w prefetcher on x86, makes it prefetching random data. This becomes quite noticeable on 10G, I've checked with Vtune.

There may be a way to re-arrange the layout of the struct so the prefetcher would stop issuing unnecessary memory reads, saving cache capacity and memory traffic. But I would not bother doing it because it is I think too x86 specific to be accepted to the kernel. And yes, I have not tested on AMD either.

As now I move from being mostly Xeon performance focused to Atom performance focused on my daily job, I recalled my old idea. Technical, goes under cut ( Read more... )

Shared cache in a CPU is a great thing for multicore - it allows efficient data sharing between cores and almost always efficiently shares capacity.

What if developer thinks cache is not shared fairly between e.g. 2 cores? There are no means to explicitly control this. But here is a workaround, a weird one though. If we write a custom allocator that only allocates data starting from addresses that go to 0-7th cache sets on 1st core, and 7th-15th sets on a second core, then we effectively make the cache a non-shared one. Unfortunately, the biggest continuous area of memory allocator could accommodate is 512 bytes then (64 bytes cache line multiplied by cache sets divided by 2 cores). The more data is allocated through this "weird cache-conscious allocator", the more fair it gets.

512 bytes cap is very annoying and thus likely not realistic for practical use, but if we would have 128-way, not 16-way last level shared cache, the cap would go up to 4k that would work naturally with OS VM mechanics :). Fortunately last level cache is tagged by physical address, so this would lift the continuous memory limit, not just make it 4k and move complexity from allocator to OS.

Upd: after careful study of prior art, it looks like I've reinvented a wheel, and made it a square one rather then round. There is a better way to partition shared cache than I've described above.

I've been doing some crypto system tuning few weeks ago and it came to my mind that the same approach could be used to solve one of the problems online casinos are facing.

Goes under cut as it's a bit technical ( Read more... )