Slashdot Mirror
Upping The Softmodem Code Bounty -- To $20,000
Alex Pilosov writes: "I've announced a bounty for completion of softmodem code (20k$) on linmodems-discuss list. If this is successfully completed, we'll have a completely universal driver for any kind of winmodem without any proprietary code which result in all sorts of kernel version problems." Here's the full text of the announcement and conditions.
I know, whore, whatever. I figured I'd mirror the text before the site goes down.
/. lameness filters.)
Begin Mirror
Well, I had almost no replies to the original post, lets see if
quadrupling bounty will help any! The bounty is now 20000$.
Please, if you are interested, contact me.
Also note that I'm interested in either completion of Fabrice Bellard's
code (on http://fabrice.bellard.free.fr/linmodem.html) or Jamie Lokier's
code (on http://www.tantalophile.demon.co.uk/)
Hi,
I'm interested in completion of Fabrice Bellard or Jamie Lokier's GPL'd
softmodem code. I'm willing to place a 20000$ bounty on this project. If
you are interested in picking this bounty, please contact me for further
details.
Notes:
* Your code will be placed under GPL
* Code must not rely on DSP, pure C required.
* You MUST have background in signal processing
* You are free to reuse other GPL'd software (virtual UART and LAP/M are
ones that are already implemented in other software).
* Pieces needed to finish:
a) v.32/v.32bis modulation/demodulation
b) full v.34 negotiation (modulation/demodulation is done)
c) analog part of v.90 and v.90 negotiation
d) virtual UART
e) v.8 negotiation of all of the above
f) v.42bis/LAPM and MNP5 (and v.42 negotiation)
g) Hayes-like AT commands/registers (integrated with all of above)
I will provide the relevant ITU specs, test hardware, and specs for
testing.
If you think the bounty is inadequate, I'm willing to talk about price.
-alex
End Mirror
(slightly modified to pass
While Linux might not be perfect when it comes to SMP, it scales better than most other operating-systems for 1-8 processors. If you claim that Windows excels in SMP, you're definitely out on a limb.
Huhhh? v2.4.14 contains ReiserFS, a fully journalled filesystem, and JFFS2, a journalled flash filesystem. v2.4.15-pre6 also contains ext3, another fully journalled filesystem. IBM's filesystem JFS is ported completely to Linux and awaiting merging, ditto for SGI's XFS, eventhough the latter has some things to sort out first. Check your facts first, please?!
I was curious about his @pilosoft.com address, but the site is blank. However, a google search on his name revealed a personal homepage.
One thing worth noting: he's 22 years old.. hmmm. According to his resume, he has contributed to apache, mod_perl, postgresql and freebsd.
My personal guess is that he has convinced one of his employers to pay for this (Lazard Ferez & Co., which he works for, seem potential, but i don't know enough about them). I'll be following the bounty thread.
Anyway, I think he is for rea and wish him good luck. Here's a picture of our hero
-Kraft
Live and let live
Have you actually looked at the drivers available in linmodems.org? look for example at the Cirrus Logic driver and look at the IBM's MWave driver - they have some common goal - they're emulating V34 and V90 protocols for example - but each chip is doing this TOTALLY differently, try to play a bit with the binary only ltmodem to see what I mean...
A unified driver won't work here since almost each DSP chip which is a WinModem is totally different from others - look at the HSF modems DSP chips (conexant) VS. Lucent WinModem DSP chips VS Cirrus Logic VS TI's DSP chip...
Or I might didn't understand you well Alex, could you give more details? You also didn't give any details about what do u offer for a group of programmers - who will get what...
Hetz (Heunique)
I mean, sure you got a modem for $10, but that modem turned your $1000 computer into an old 386 for any tasks beside running the modem driver.
Its explictly required that the driver in question doesn't rely on DSP code which then translates the project into:
Bounty $20000 for developing an application that will bring your computer to a crawl.
Thomas S. Iversen
THis is a copy of
this article on zdnet. completely copied including spelling errors.
by Kai Vuorinen
date: Tuesday Oct 12, 1999.
Is this still all true?
WinModems, in contrast, are just a big hassle: they consume oodles of CPU time, they have non-standard drivers, and you have to worry about them with every OS. If your laptop has one built-in, complain to its manufacturer (it probably would have cost nothing to add a real modem) and don't bother using it.
This is intended to prevent that unattended systems, where the phone number of the peer is misset for some reason, accidentally harress an innocent third party all through the night by calling every five minutes...
A low level driver could easily bypass such rule, which would theoretically make it necessary to certify it.
Say no to software patents.
Note that he found a hardware PCMCIA modem, inexpensive no-name, but he insisted to the salesperson to try it in his laptop before purchasing. He was lucky the salesperson allowed it. Oh, if you want a 3Com PCMCIA WinModem, I think he'll be happy to sell it to you. It won't be used anyway. :-)
I only have one modem, and old 33.6 TDK which I use occasionaly in my old laptop (for downloading email). That modem dates back from the times that softmodems were nonexistent, and everyone would have found it very strange to actually emulate a modem in software. Ah, the good old times.
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
Interesting; I did not see this second message from Alex. Have I been unsubscribed from the list over the weekend, I wonder?
I'm going to answer a few questions that have been raised, and a few that haven't.
Is anybody working on the code?
Fabrice started first. Unfortunately, he has been quiet for a very long time, and I have no idea if Fabrice has done further work on the modem code. I hope he is still well and healthy.
Meanwhile, I have been secretly still working on my code base (that's the one at tantalophile) all this time. It has been an on and off affair, and I've found it difficult to find the time, energy or focus what with the day job and other projects. I keep foolishly trying to improve on the standard algorithms ;-) Nevertheless, bugs have been fixed, features added, tests done, signals are processed better than ever and I have a nice set of graphs showing simulated error performance of the V.34 core under various conditions.
In other words, there's a long way to go and please, nobody hold their breath, but there has been substantial progress and it is not on the tantalophile web site. So don't slashdot it, thanks :-) I'm making no promises about when my new material will appear, but I do promise it will be announced on the linmodems mailing list.
About the bounty
It's a bit of a nice surprise to see that offered. I'll be contacting Alex, but to be honest I am motivated to complete the project anyway. I don't want funding to dictate the goals of the project (which should be educational and of high quality, IMHO, as well as functional), although some influence would be understandable. It is likely to make a difference to the schedule though.
Legal clarification and/or commercially backed negotiation on the patent issue would be invaluable, and help with testing is also very valuable.
I didn't respond to the original $5000 request because it is not a lot of money. Considering the large amount of time, effort and to some extent resources already spent on the project, as an estimate for the remaining work, I would certainly not accept a commercial contract at that sort of rate. $20000 is rather more interesting, but I think Alex's request for V.90 is unrealistic if he wants it on a short timescale.
One thing that would be a bit upsetting is if all my work were quickly overshadowed by someone else, suddenly motivated by cash, throwing something together. But I cannot complain as I haven't exactly been speeding ahead or keeping with the community on this. I know how the Hurd feels ;-)
Standards compliance, approval, and "homologation"
This is quite hard, because anyone can modify the code and thereby break any certification of the code.
Different countries have different standards. There are differences in the energy that can be emitted, both the peak instantaneous energy and a longer term average are limited. And you don't always want to max out the energy anyway, as you're avoiding distortion.
The relationship between voltage and current is not the same everywhere. Dialing tones, engaged tones and so on vary. V.90 coding varies because the USA operates at a lower digital bit rate than most of Europe.
Some people have said that it is the hardware which is subject to regulation. This is not true. I believe there is a certain certification level for the hardware itself, for avoiding excessive energy input, making sure the hardware doesn't go up in flames when receiving the 100V ring pulses or a lightning bolt, that the impedance is matched, and so on.
However, it is (theoretically) necessary to certify the software as well for many reasons. A good example: by modifying the software, you can transmit more energy on a USA telephone line, using a USA modem, than is permitted by federal regulations. That excessive energy is considered to potentially interfere with other people's telephone calls. So, you do have to get the software right.
Fortunately we have a good example of certification in the Linux kernel. Some versions of the Linux ISDN code are certified for use on the German telephone networks, I believe. The source code is checksummed. I note with interest that it's the source that's certified, and not the binary (so the beurocracy is ignoring bugs in the compiler or the rest of the kernel).
For myself, I am very keen to write code which certainly does conform to all the known requirements. I don't feel comfortable hacking together some "it seems to work" code of this kind and releasing it like that. It's partly a reputation thing, and partly a responsibility thing.
On patents
Yes, there are many patents. Unfortunately the detailed patent situation is unknown. It is possible that the patents don't apply to software implementations in most countries, but we don't know to what extent and where each patent applies.
We don't even know which patents apply! However, there is an online list at the ITU which may be helpful.
This is hopefully an area in which Alex Pilosov and his (possibly) commercial backing can help in a big way.
I am of the opinion that users have, in general, already paid for their modems and so they should already have permission to use the techniques. It seems to be the case that software modem drivers for Windows are downloaded and installed with no attention paid to these matters, so it should not be any more of an issue for Free Software. It would be good to know for sure.
The developing world
Telephone line driver chips are cheap! For the developing world, getting an internet connection over crappy copper would be a wonderful achievement, and with full access to a software modem, you could cobble the modems together from parts.
For this reason I think it is important that the softmodem works well over poor lines as well as good ones. And yes, I would love to code "workarounds" for when the standard algorithms don't perform well on Nepalese copper lines, or wherever. It would have to be a special variant of the code, for the regulatory reasons stated earlier, but it's a lovely thought.
Is it still worth writing a software modem in order to use "winmodems" on Linux?
The motivation has certainly waned, now that many previously windows-only modems are now supported on Linux by binary-only drivers from the manufacturers. Of course, you cannot use them if you're using the wrong kernel, or SMP, or if you have more than one modem, if you don't permit binary-only drivers, if you are using an Alpha or a PPC-based iMac, or if you want to run any-BSD. But hey, a lot of users are happy enough now, so that does remove some of the motivation for writing the code.
Which leaves the educational aspect. The interior of a modern modem is not well documented, even in books about signal processing. To be sure, many of the classic algorithms are very well written up, but the details as they apply to modern modem standards are not, and there are some algorithms which V.34 and V.90 clearly require which I have yet to find any information about. (Welcome to re-inventing the wheel, but it is fun!) As Alan Cox once said, the V.90 standard is "semi secret". Read it sometime, if you don't mind paying the relatively modest fee, and you'll see what he means.
Revealing just how a modern modem works, in the form of working code that (I hope) is readable by those who wish to study it, then, is as much a goal for me as getting winmodems working. And it's interesting because I'm still figuring it out myself :-)
Interfacing with the hardware
Several people pointed out, quite correctly, that a software modem won't actually work with any of the hardware "winmodem" devices. This is correct; we need device drivers too, and that is accomplished by reverse engineering the original drivers.
I don't know Alex's exact requirements. He doesn't mention needing PCM drivers -- perhaps he has his own drivers already? But if he requires reverse-engineered PCM drivers as well then that's quite a bit more work.
Progress on that front is being made, by several people, but it is really a separate project. It is worth noting that there's a GPL'd Lucent modem driver that can do PCM. It is actually quite old now. I have faith that the PCM driver part of this problem will be solved by eager contributors if there is a good softmodem to make use of it.
Cheers,
-- Jamie
To my knowledge, there are no patents that would hinder this particular development.
Notwithstanding this, there ARE patents in the general area:
SMLink has bunch of patents, but they are all (again, to my knowledge) in hardware-chipset area, not in driver area.
PCTel also has patents in the same area.
Rockwell and Agere have patents in DSP-modem area.
There are patents for the algorithms involved in v.34 and v.90, however, I believe they all can be either avoided (by implementing differently), or denied by presenting prior art, however, they are the biggest threat.
These patents are owned by PCTel and SMLink. I'm still in process how to avoid them.
Uh sorry, that ain't me, there's another person
with same name (my distant relative).
No, this has absolutely nothing to do with Lazard. I'm a mere IT consultant there, and they know nothing about this.
The money involved is my savings, that's it.
Hardware-specific code is actually out there for many devices. At any case, reverse-engineering of each piece of hardware can be done later once this is completed.
No, I am not related to any manufacturer of any winmodem-related device.
I'll be brief with the hurdles you will have to overcome:
Motorola holds the base patents on host signal processing, and I'm not sure how the Open Source community can get around those patents. Given Motorola's hard times, I doubt anyone will convince them to provide a royalty-free license to the patent -- especially as they have a soft-modem product in the race. (But then again, they concentrate in the Windows marketplace, so a Linux license could happen...maybe...if the moon is right.)
Then there is the CPU intensive nature of HSP modems. Depending on the quality of modem you are trying to do, CPU horsepower requirements are huge. A bare-bones V.34 implementation requires around 40 MHz of a Pentium-class CPU, while a robust bells-and-whistles version needs something like 90-95 MHz. Don't expect a 486 to handle the load. To be as good as possible on as many platforms as possible, the signal processing code would have to use integer arithmetic instead of floating-point, because the floating-point performance of x86 class processors varies quite a bit from chip type to chip type.
Can it be done? Yes. Can it be done to the expectations of the Linux community? I don't think so, unless one of the big boys (Motorola, Connexent, Nortel, USRobotics) decides to weigh into the market and provide already-developed code and an interface.