"the chosen approach resolves collisions only up to a certain degree. If, however unlikely, a further key maps to the same hash index, then the request simply fails and an appropriate response is generated. We believe this to be an acceptable behaviour for what is essentially equiv-alent to a cache full/miss."
So it's more like a cache than a key/value store? Nothing wrong with that but to me a key/value store implies that data isn't lost in the case of a hash collision. Pretty cool stuff nonetheless.
What I'm not getting from this is why it's any different from a properly implemented TCAM.
Key/value lookups are something that's done by existing networking hardware very well. There are existing merchant-silicon chipsets that do this on-die very well.
There was once an evolving market for "network processor units" but it looks like that all cooled down. IIRC, there was an effort to do something akin to a database lookup on an NPU, but the tradeoff between flexibility and what the NPUs could provide wasn't amenable to the kind of work required to bring those solutions to market.
TCAMs have three problems for such applications:
1) limited key length (usually less than 64 bytes)
2) power-hungry as you are comparing against every key
3) limited size -- try getting a 4GB TCAM!
At least as far as I understand the article, it's simplified in that it can drop store requests without breaking its semantic guarantees. Implementing full CAMs on FPGAs is pretty inefficient.
Something's fishy. What was your measurement platform? It feels like, you should have been doing much better than "4-5us" (what was your 99.9 percentile, BTW?) with your FPGA approach. Unless you are doing TCP/IP. But it looked like you are not, right? It is just UDP?
Rather than go to class I created a popular custom discussion forum for students to help each other with the homework problems (back in the early 2000's). Ended up teaching myself perl, html, css, javascript and sql in the process which landed me my first job. Never had to do my physics homework (useless busywork) because the answers were posted on the forum. Still received grades of B+ or higher.
wow, why the downvote? I'm very proud of the website I created. It was what got me started with programming and lit a fire under me to learn new programming languages. I don't share much on HN but a downvote to this post makes me want to refrain from ever sharing.
[Original message removed due to another downvote. I guess I will not share personal anecdotes anymore. I feel that downvotes are for off topic or mean comments. I only shared a personal experience that I felt related to the OP's story.]
Sharing personal anecdotes is fine. You however seemed to be espousing cheating the system. You didn't go to class, and instead built this collaboration system (which is awesome) but then used it to cheat (not so awesome).
> You however seemed to be espousing cheating the system.
Doesn't that sound similar to hacking the system? We are using a website called hacker news. Not only was collaboration on homework encouraged, but the class actually had its own discussion forum for people to use. However, everyone disliked the forum because it was cumbersome and slow. So I built my own. At the end of the semester I had many people thank me for the website and asked to have it expanded to cover more classes. Using this forum I personally helped many students understand concepts and taught concepts that the professors couldn't teach properly. There were a few subjects I didn't understand and other students stepped in to help. You were not in my class and did not use this forum so I don't think you should rush to judgement about what was/wasn't cheating.
By definition, hackers do things that push boundaries. There will always be disagreement but you don't have to downvote just because you disagree. Voice your opinion, certainly, but please be careful with those downvotes.
"Doesn't that sound similar to hacking the system?"
Ha. No. The system is designed to make you learn about physics, in this case. You did not learn about physics. You actually hacked the system to take your time and money and not give you a good result.
>You actually hacked the system to take your time and money and not give you a good result.
And what if I earned 100% on the 2 midterms and a 94% on the final? I got a 96% in that physics class. Other students told me that their exam grades improved after starting to use the forum. Not sure how I didn't get a good result. Again, I'd like to say that rushing to judgement of other people's situations isn't beneficial to anyone. I feel as though my initial post was very on topic and was kind of hurt when it was downvoted within a few minutes. We're all here to help and support each other.
By the way, I'm new to posting on HN and am wondering how you made your text italics?
You're assuming that a particular grade is a good result. It's an issue I think a lot of students have -- I certainly did. And it's not exactly the fault of students... The whole system seems geared towards the "good grade = success" metric. It's a weird kind of institutional laziness.
I don't know your specific situation, and I also don't really care if you cheated in your class and still got an A. And I'm happy that you got some programming skills out of it! But -- as someone who now teaches at a couple of universities -- I want students to be engaged, to not treat the work cynically, and to actually do the work I assign. As a professor, I am not only more experienced than you, but I know a lot you don't know. Trust me. That's why they hired me. If you consider the class nothing but useless busy-work, get out of the class. An engaged student who tries hard and gets a C is preferable to a student who does show up, cheats, and gets a A. That C is way more respectable than the A and the C student should take more pride in it than the A student. (And it's sad that our system doesn't really allow that.)
Don't get confused about what the actual goal of education is.
Thanks for teaching me the italics trick! I promise, I love to learn!
I agree with most of what you said. In fact, it's due to a few of my classes (especially that physics class) that I'd like to become a professor some day. I want to teach kids much better than those few terrible professors I had to learn from (I had no other choice in teacher).
> If you consider the class nothing but useless busy-work, get out of the class.
Trust me, if I could have I would have. Unfortunately these classes were prereq's for the classes (and major) that I cared about. I knew the material well enough to get decent grades and didn't care beyond that. I would have gladly traded a seat for a student who cared (especially a student who couldn't afford to go to college!)
I still think this is an abuse of down-vote priviledges... downvote should be used to bury non-constructive comments, not express disagreement with a point or behavior. (That's what comments are for.)
Thanks for sharing. This was an awesome read. I'm surprised the router allowed external connections to access the internal configuration. However, some older routers are pretty poorly designed from a security standpoint.
Failing immediately is certainly an easy way to handle unrecoverable errors. However, it seems as though your library assumes NDEBUG is never defined. Maybe you should make your own function rather than using assert()?
The asserts are in the .c files. Defining NDEBUG in your program won't change anything in lthread because the library was compiled without NDEBUG defined.
If you want to define NDEBUG when compiling lthread, that's up to you.
with NDEBUG, foo will never even be called. I've seen some funky bugs from this in the past, like people calling malloc inside an assertion... Works great during dev, release build has NDEBUG defined, no test coverage... You get the picture.
A better idea would be to capture the return value in a var and do the assert on the var.
Yes I understand that foo() won't be called if you defined NDEBUG. But when compiling lthread, NDEBUG is not defined anywhere in the code / makefiles so it's guaranteed to be called and I want to assert the returned value.
I don't disagree that public APIs should be well documented. However, I believe it's very easy to forget to update the comments. Especially in scripting languages without type safety. There is little to remind the programmer that arguments were added, types were changed, argument order was modified, behavior was changed, return value was changed, locking behavior was changed, memory allocations were changed, etc. Obviously unit tests should help catch many of these changes. However, it's still up to the coder to remember to change the comments. When you're behind on a deadline or you're juggling 50 different API changes because you're still alpha I'd say it's pretty easy to forget to update a comment.
See http://api.jquery.com/jQuery.ajax/ if you want an example of on API that could easily have a few typos in it. Who is checking to make sure it's 100% in sync with the code 100% of the time? Not trying to say this example has bugs in the docs but there's a LOT of behavior described that could be out of date.
But the solution is to make sure that the documentation is of a sort that is useful in determining where to fix things. Again, if you have a problem with a function call, the fist question should be "does your call to the function match the documentation?" If it doesn't the first thing you do is change the call to match.
Now sometimes one comes to the conclusion that an API is broken, so you have to modify the comments, and then modify the code, but there is a reason to do it in this order.
When you modify the comments you are modifying a set of promises you have made to other coders. This allows you to think through how this change is going to work and how it will affect other code out in the wild. Then, when you modify your code, it is going to be better.
If you're forgetting to update the comments frequently enough to be a problem, you're probably forgetting to update the code that consumes the API too. That quality in general falls by the wayside when you're crunching is no reason to abandon quality altogether.
Forgetting to change the code that consumes the API means that things don't work, which is visible right away. Forgetting to change the comments will be visible gradually and cruft accumulates. Also, sometimes comments wind up being non-local and just aren't noticed. I agree that in some senses it's "no excuse" but that doesn't mean it won't happen. Documentation that can break visibly when things change is better than static documentation.
> > Forgetting to change the code that consumes the API means that things don't work, which is visible right away.
> Oh how do I wish this were the case!
It's certainly not always the case, but it's a whole lot more likely to be the case than for unchecked documentation.
> > Documentation that can break visibly when things change is better than static documentation.
> Agreed, but I would not call your average run-of-the-mill unit tests "documentation",
I think "is it documentation" is probably more of a spectrum than any particular threshold, and run-of-the-mill unit tests probably do fall on this spectrum though I'd probably agree that they're not particularly far along it (though that surely varies with the habits of those writing the tests).
> nor can all documentation can be programatically tested.
As a practical matter, that's certainly currently the case - tooling is not set up for testing documentation, and there are things we'd want to check that would be hard to check in any event. Theoretically also, there are certainly properties that can't be statically demonstrated. I'm not entirely convinced that there's nothing we're interested in that couldn't eventually be got at for the programs we care about, though it's certainly a possibility. Regardless, it seems an ideal worth pushing towards, and if tested documentation is interwoven with untestable documentation such that some conceptual locality is preserved it's less likely (though absolutely still possible, to be sure) that you'll forget to update the other when you're forced to update the one.
This whole problem stems from the movement to privatize prisons. It's a disgusting abuse of power. The lives of many at-risk children (and their families) have been turned upside-down due to greed.
So it's more like a cache than a key/value store? Nothing wrong with that but to me a key/value store implies that data isn't lost in the case of a hash collision. Pretty cool stuff nonetheless.