Netzwerk-Chip wechseln?

Zitat

Original von Da_Flex
Unter den Gehörnten geht's manchmal etwas ruppig zu.

Na dann werd ich mal brav meinen Schneeball weiterrollen. ich habe keine Angst vor euerem Feuer Davon lebt halt die Diskussion, nicht wahr?

Ciao Trude

Hallo SadButTrue,

> ich hab keinen teufel sondern nen daemon (Beasty)...

Naja Deamons gibts ja bei Linux genug, wäre halt besser wenn da auch mal ein funktionierender Netzwerk-Deamon für die DM500 darunter wäre.

This is from another thread that I newly started...

Have another idea:

Does anyone know if the network chip of the dm500 has a dedicated quarz (which is sometimes the case). Perhaps the caps around the quarz are of the wrong type. Normally, they must be of the type COG (very high stability over wide temp and time) and depending on the chip balancing and loading on the XTAL pins somewhere around 22pF. More than once, have I heard that the network bandwidth decreases over time which would favour my assumptions of the wrong type capacitor material.

This could also explain why the copy works: they accendentally used the right quarz filter.

Hello johnbock,

nobody knows the circuit of the DM500 for sure, since it is not public, but on the photo of the sourroundings of the networkchip you can see a quarz-oscillator very close to this chip and far from the CPU so it seems to be obvious that this oscillator is dedicated to the network-chip.
Besides that Ghost1981 posted a link to the datasheet of this networkcontroller earlier in this thread from which it should be pssible to see if this chip normally uses such a dedicatedcoscillator.

There was allready discussions about capacitors of the networkchip in other threads, sinnce the DM7025 had a problem with capacitors of the networkinterface, but as far as I understood that were filtercapacitors for the powersupply of the networkchip not the oscillatorcapacitors. Nevertheless thesse threads ended with the resault that the capacitors seem to be OK.

besides that earlier in this thread SadButTrue (a reliable member of the IhaD team) stated that he has reliable information that the networkproblem of the DM500 is a softwareproblem and DMM is working on it, only nobody knows if or when there wiil be a fix available.

Hi,

I've taken a look at the data sheet for the nic and the reference designs of the quarz filter from asix. Having used other microprocessor of this class I can say from my experience that the filter dimension is not typical.

I personally, don't want to open my receiver until the warranty has ran out sometime next year. Furthermore, I would not suggest to anyone to hand solder a LQFP. I've done it several times... It's no fun at all, very error prone and may lead to a desaster. And you alone may have to carry the consequences.

@chirwi
I suggested it may be a timing problem because of the massive memory expendetures that I have encountered here and because of the rumors spreading about, concerning the china dm500 copy working net-if.

I've been successfull (not here) in correcting such hardware problems by trimming the interrupt scheduling/buffers in or around a given driver. Has any tried running the nic in 10Mb/[FH]D, can the driver handle this "on the fly"?

Hello johnbock,

according to what you write, in my opinion , you are one of the most competent persons here in the forum who ever conquered this problem, and I am following this toppic for already more than one year. Unfortunately I myselfe know almos nothing about lowlevel network-hardware or software, evenso I am also professionoal in embedded software development but only in the automotive-sector wherte there is only CAN instead of ethernet and linux.
I hope you can find some other members woh can give you the necessary information to enable you to solve this ugly problem.

john & Criwi

If you are correct and the problem is the stability or accuracy of the ethernet interface clock, maybe it would help to force the speed down to 10MBit. Of cause you have to keep the Auto-Neg on to be sure the you get Full duplex when you connect to a switch.
The ethernet protocol allows to provide 10BT/FDx in the FLC but i don't know is it possible to set it with the DM500. I'm also not so experienced with linux (this i want to change) so i don't know is there a possibility to set this via telnet.
Maybe to test this you can switch off Autoneg and set the speed to 10MB/Fdx (i still don't know how to set in linux). But the you have to connect the DM500 directly to a PC with a cross cable and set the ethernet interface of your PC also to 10BT/FDx.
Of cause i can also test this but i have a DB500T. Because of the lower bitrates wich are transported by DVB-T the streaming works and this test makes no sense
I think 10MBit should be still enough for streaming. It was enough for the dboxII.

Hi chriwi,

I'm sorry that I may have mislead you to think that I'm compentent in this field. But I was a specialist for embedded hydralic control feedback systems for industrial applications. Most were special implementations with self-made microkernels & microdrivers: most systems were not larger than 100KB. And I have only basic experience with embedded linux.

I haven't been practicing in this area for almost 7 years now. And have no access to any jtag debuggers, oscopes nor to spectrum analysers. So please do not get hopes too high.

The ideas that I have thus far, are only that ideas. These are generalisations that have been made on a (mostly) hardware basis. But I do believe that if we work constructively together on this problem, we may be able to help dmm find a solution for the problem.

tweety & chriwi: you see once people start working together the ideas just start jumping out at you...

Unfortunely, I believe to get to the bottom of this problem, one must compile a version of the kernel with an absolute minimum of built-in modules. Load the one or other module (in particular the network module) and perform a series of well defined repeatable tests (test-bench if you like). In that way, we may be able to conclude that our problem has or does not have to do with a particular subsystem. Almost like natural selection.

And another idea... Knowing that streaming in data into the receiver works as required and streaming out works well in low cpu load situations, one could conclude that the device driver supports only dma (rcvr) in. This does not neccessarily void the ideas that I have previously voiced: it merely shows that the problem may be manifold.

As I see it know we have three ideas:

1) The device oscillator may be working inaccurately enough (because of intolerant components?) to provide timing problems: where ever timing difficulties may lay.

2) An partial solution may be to set the network interface into 10Mb/s and observing the guidelines as proposed by TweetyMH

3) The device driver is only partially complete. In which a posed second (xmit) dma may provide a solution.

I hope we can develope some kind of stategy to test these hypotheses. I am completey open to any constructive suggestions. And one thing that we must remember is that for the most of us; this is only a hobby:)

i've just got another Idea

when you connect the ethernetcable the connected interfaces are "talking" who is the clock master for this connection. So maybe this is an explanation why some user has no problem. when the clock master is the Box you may get a problem. when the connected device is the master maybe it works fine.

I'm working in a big german electronic factory and i'm SDH (mainly next gen.) and DWDM specalist. So i have access to an Osciloscope and a spectrum analyzer. Also we have some ethernet testsets.
If i don't forget i will take my box to work and connect it to an ethernet testset. At least i can say how much is the offset of the clock when the box is the master.

Hey that sounds good:) But please donot get yourself into trouble!)

If you like you guys can write german and I'll continue to write english.

I can read german quite well, but cannot write it well enough to be always understood the way I meant .

Sorry, but I don't understand the acronyms SDH & DWDM.

Hallo,

wannauchimmer man mal wieder irgendwelche inofiziellen Informationen von DMM zu diesem Thema bekommt heist es immer wieder:
- Das Problem ist bekannt
- Es ist ein Softwareproblem
- sie arbeiten dran und zwar speziell an nem neuen Treiber für den Vulcan-Chip (das ist meineserachtens der Hauptprozessor und nicht der Netzwerkchip), da sol es angeblich ein Feature geben das bisher vom Treiber noch nicht genutzt wird, aber schienbar die Netzwekperformance verbessern könnte, vieleicht irgend ne Art DMA.

Leider wird das schon lange gesagt und es hat sich bisher leider nichts getan, vielleicht gibts ja was neues wenn die DM600-PVR auf dem markt ist.

Vielleicht helfen diese Informationen hier ja irgendwem weiter, mir leider nicht.

Zitat

Original von chriwi
- sie arbeiten dran und zwar speziell an nem neuen Treiber für den Vulcan-Chip (das ist meineserachtens der Hauptprozessor und nicht der Netzwerkchip), da sol es angeblich ein Feature geben das bisher vom Treiber noch nicht genutzt wird, aber schienbar die Netzwekperformance verbessern könnte, vieleicht irgend ne Art DMA.

I've heard that dmm knows where the problem is, and that they are supposedly working a solution. But, I didn't know that the "driver" problem is concerning the processor.

Thanks for the information.

Zitat

Original von johnbock
...
Sorry, but I don't understand the acronyms SDH & DWDM.

most people don't ...
http://de.wikipedia.org/wiki/SDH
http://de.wikipedia.org/wiki/DWDM

english is not such a big problem for me
but ok ... dann eben weiter in german ...

Ärger krieg ich beim testen sicher keinen ... Im gegentleil ... wenn das ein Kollege mitbekommt, guckt er mir eher neugierig über die Schulter ...
Ich mache sog. Kundenabnahmen. Leute von I-Net, mobile oder Festnetzprovidern aus der ganzen Welt kommen zu uns und überprüfen ob unsere Systeme auch den Standarts entsprechen.
Wenn keine Kunden da sind sind die Messgeräte frei und ich hab eher ruhigere Tage auf arbeit ... da passt sowas locker dazwischen ...

Ok ... zurück zum Problem
Je mehr ich darüber nachdenke, desto weniger glaube ich an ein Talktproblem. Ethernet ist durchaus in der lage mit taktabweichungen zu arbeiten. Um aufgrund der Taktabweichung fehler zu bekommen, müsste die Abweichung so gross sein, dass sie innerhalb eines Rahmens bitfehler Produziert.
Zu beginn eines jeden Rahmens gibt es die sogenannte Preamble. Diese dient unter anderem dazu, dem empfänger die gelegenheit zu geben, sich auf den Takt zu synchronisieren. Nachdem ein Rahmen gesendet wurde, muss der Sender ein pasue von 12 bytes machen. Der Emüfänger muss aber auch Rahmen akzeptieren, die früher kommen (minimal akzeptierte pause ist 11 bytes). Nach diese Pause wird neu synchronisiert.
Bei einer Rahmenlänge von 1518 bytes muss man dann eine Taktabweichung von >10^-4 haben um fehler zu bekommen. bei kleineren Rahmen muss die Taktabweichung noch grosser sein.

nagut ... hab die Kiste natürlich zuhause vergessen ... morgen werd' ich keine Zeit haben zum messen ... also Freitag ... wenn ich's nicht wieder vergesse.

Hallo johnbock,

ich weis leider auch nicht genau was sie das entwickeln nur fällt halt oft das Schlagwort Vulcan-chip und das ist der IBM-PPC-Controler für Settopboxen, mehr weis ich nicht.

johnbock
Das DMM an einer Lösung arbeiten sagen sie schon seit 1,5 Jahren!
Ich glaub nicht mehr daran.

Schaut auch mal diesen Thread im DMM Forum an. Da wird von einem Moderator auch die Behauptung aufgestellt, dass vielleicht eine Lösung gefunden wird wenn die 600er draussen ist.

-> http://www.dmmtv.de/board/thread.php?postid=14797#post14797

MfG
ghost1981

Hallo Ghost,

> Ich glaub nicht mehr daran

da gehts mir ähnlich, zuletzt hieß es halt sie brauchen ne Lösung bevor die DM600-PVR auf den Markt kommt, aber auch das scheint nicht mehr der Fall zu sein. Das ist ja wohl auch der Grund warum gerade jetzt diese Diskusionen wieder hochkommen, weil es Gerüchte gibt jemand von DMM hätte auf der IFA gesagt das würde auch bei der DM600-PVR nicht besser.
Andererseits hat Sad ButTrue weiter oben in diesem Thread nochmal geschrieben:

> wie oft muss man es noch sagen das es keine hardwaresache ist
> sondern ein teiberproblem war....

und scheint daran zu glauben, was mir dann wieder Hoffnug macht.
Wenn da nur nicht das ewige warten und diese Unsicherheit wäre, das nervt.

I think it depends... If the 600'er really does have the same hardware configuration as 500'er. I've heard conflicting reports.

Some say it has comparable hardware (cpu, nic) as the 7025 und some say it has that of the 500'er. But I have seen nothing official:(

the 600pvr uses a IBM Vulcan PPC-CPU not the ATI Xilleon 226 this is a fact!

everybody who says different things doesnt know anything!

SadButTrue

Do you have any more hardware information about the 600pvr that you can share with us?