mboost-dp1
Nye features til IPv6 test
Jeg har ændret teksten så den nu siger "Du har hentet 14 ud af 20 tiles inden for 2 sekunder."freesoft (70) skrev:14/20, men der mangler nu kun 2 billeder. 22 og 34.
Er den formulering præcis nok, eller skal den sige "Du har hentet 14 ud af 20 tiles inden for 2 sekunder og ikke flere tiles de næste 3 sekunder."
Jeg lavede lige en statistik måned for måned på hvordan fordelingen var på antal brugere fordelt i tre kategorier:
1. Kategori fuldt funktionel IPv4 (henter 8 af de 20 tiles)
2. Fuldt funktionel IPv4 og IPv6 (henter alle 20 tiles)
3. Har et problem (alle andre kombinationer)
May 66% IPv4 14% IPv6 20% Problem
Jun 41% IPv4 52% IPv6 7% Problem
Jul 52% IPv4 38% IPv6 10% Problem
Aug 48% IPv4 38% IPv6 14% Problem
Sep 50% IPv4 20% IPv6 30% Problem
Oct 84% IPv4 9% IPv6 7% Problem
Nov 59% IPv4 34% IPv6 7% Problem
Dec 59% IPv4 23% IPv6 18% Problem
Jan 84% IPv4 11% IPv6 5% Problem
Feb 74% IPv4 13% IPv6 13% Problem
Mar 69% IPv4 23% IPv6 8% Problem
Statistikken skal selvfølgelig tages med en række forbehold. Det er begrænset til brugere, som har tilgået testen. Det vil sige for få til at være et repræsentativt udsnit af noget som helst. Og er nok skævt fordelt da personer som prøver at sætte IPv6 op eller som har et problem nok vil være overrepræsenteret i sådan en test.
Jeg burde nok også lave lidt mere statistik på brugere med et problem for at kategorisere problemerne. Ikke alle brugere med et problem har lige store problemer. Jeg har ikke taget højde for urimeligt langsom indlæsning af siden i ovenstående statistik, så procentdelen med et problem er nok lidt højere.
1. Kategori fuldt funktionel IPv4 (henter 8 af de 20 tiles)
2. Fuldt funktionel IPv4 og IPv6 (henter alle 20 tiles)
3. Har et problem (alle andre kombinationer)
May 66% IPv4 14% IPv6 20% Problem
Jun 41% IPv4 52% IPv6 7% Problem
Jul 52% IPv4 38% IPv6 10% Problem
Aug 48% IPv4 38% IPv6 14% Problem
Sep 50% IPv4 20% IPv6 30% Problem
Oct 84% IPv4 9% IPv6 7% Problem
Nov 59% IPv4 34% IPv6 7% Problem
Dec 59% IPv4 23% IPv6 18% Problem
Jan 84% IPv4 11% IPv6 5% Problem
Feb 74% IPv4 13% IPv6 13% Problem
Mar 69% IPv4 23% IPv6 8% Problem
Statistikken skal selvfølgelig tages med en række forbehold. Det er begrænset til brugere, som har tilgået testen. Det vil sige for få til at være et repræsentativt udsnit af noget som helst. Og er nok skævt fordelt da personer som prøver at sætte IPv6 op eller som har et problem nok vil være overrepræsenteret i sådan en test.
Jeg burde nok også lave lidt mere statistik på brugere med et problem for at kategorisere problemerne. Ikke alle brugere med et problem har lige store problemer. Jeg har ikke taget højde for urimeligt langsom indlæsning af siden i ovenstående statistik, så procentdelen med et problem er nok lidt højere.
Relateret til IPv6, så opdagede jeg lige at Google Public DNS er begyndt at understøtte IPv6. Det gjorde den ikke sidst jeg checkede. Er her nogen som ved, hvor længe det har været supporteret?
Nu mangler de bare at få deres egne autoritative DNS servere på IPv6 og få IPv6 support i gmail.
Nu mangler de bare at få deres egne autoritative DNS servere på IPv6 og få IPv6 support i gmail.
Nej, testen bruger ingen scripting på klienten overhovedet. Det kan også bruges på en browser uden javascript. Alt der kræves af browseren er at den er i stand til at hente billeder og iframes parallelt over to TCP forbindelser. Det er de fleste browsere i stand til.Tukanfan (111) skrev:Er det noget browserkode der afvikles
Fra IPv6 adressen. Nogle IPv6 adresser er genereret udfra netkortets MAC adresse. Hvis man besøger siden med sådan en IPv6 adresse vil min kode finde MAC adressen i IPv6 adressen og slå den op i oui.txt.Tukanfan (111) skrev:hvor fås informationerne fra?
Jeg tilføjer sikkert også snart en feature til at vise MAC adressen. Det kan jeg lige så godt, så har man lidt mere information på den måde.
Den første bruger som testen kunne vise oplysninger om mærke på netkortet var inde på siden mens jeg skrev dette indlæg. Før det var der to andre brugere inde, som dog ikke kunne få vist oplysninger om netkortet.
Der var en bruger inde på siden gennem en Teredo klient. Bruger man en Teredo klient er oplysninger om MAC adressen ikke synlig. Teredo adresser er aldrig baseret på MAC adressen.
Der var en anden bruger inde på siden gennem 6to4. Jeg tror det var en automatisk tunnel sat op af Windows, i hvert fald havde adressen en struktur som ligner den som Windows bruger.
Når Windows sætter 6to4 op vil de sidste 32 bits af IPv6 adressen være en kopi af IPv4 adressen. Og en 6to4 adresse har også en kopi af IPv4 adressen tidligere i IPv6 adressen. Så man kan se at disse 32 bits går igen to gange.
IPv6 adresser med oplysninger om MAC adressen kan sagtens bruges med 6to4, det er bare ikke noget, som Windows gør som default. Hvis man har connection sharing er der til gengæld mulighed for at testen kan se MAC adresser på andre computere på det pågældende LAN.
Jeg konstaterede at det er meget få brugere, som har en synlig MAC adresse. Her er en komplet statistik over de MAC adresser jeg har set på testen i al den tid den har eksisteret:
1 ASUSTek COMPUTER INC.
3 Apple
3 Apple, Inc
1 Askey Computer
1 GIGA-BYTE TECHNOLOGY CO.,LTD.
1 HTC Corporation
1 Hon Hai Precision Ind. Co.,Ltd.
1 Hon Hai Precision Ind.Co.Ltd
3 Intel Corporate
1 ASUSTek COMPUTER INC.
3 Apple
3 Apple, Inc
1 Askey Computer
1 GIGA-BYTE TECHNOLOGY CO.,LTD.
1 HTC Corporation
1 Hon Hai Precision Ind. Co.,Ltd.
1 Hon Hai Precision Ind.Co.Ltd
3 Intel Corporate
Jeg har lige rettet en fejl som gjorde at en person blev vist denne fejlagtige besked:
Den fejl var tilpas dum til at det er kun rimeligt at jeg giver en kvajebajer til personen som blev udsat for den besked. Når vedkommende møder mig må han blot oplyse den korrekte MAC adresse for at bevise at han er den retmæssige modtager.
For de nysgerrige er den fejlbehæftede kodelinie her:
Din MAC addresse er: 00:00:00:00:00:00 (XEROX CORPORATION)
Den fejl var tilpas dum til at det er kun rimeligt at jeg giver en kvajebajer til personen som blev udsat for den besked. Når vedkommende møder mig må han blot oplyse den korrekte MAC adresse for at bevise at han er den retmæssige modtager.
For de nysgerrige er den fejlbehæftede kodelinie her:
qsort(mac_address, mac_addresses, 16, compare_mac);Det skulle være åbenlyst for enhver hvad fejlen er.
Korrekt.Tukanfan (120) skrev:Kan det passe der skal stå 6 istedet for 16?
Selv for mig som har skrevet koden gik der et minuts tid fra jeg havde opdaget fejlen til jeg forstod hvordan den fejl kunne resultere i førnævnte symptom. Så der er ikke noget at sige til at du ikke ud fra den ene linje kan se sammenhængen mellem fejlen og symptomet.Tukanfan (120) skrev:Hvordan det desuden er blevet til den omtalte fejl
Den nævnte linje sorterer et array med MAC adresser. Der kan være dubletter, de vil i så fald blive fjernet efter sorteringen. Der kan dog kun være dubletter, hvis samme MAC adresse har været embedded i flere forskellige IPv6 adresser.
I mine unit tests blev den pågældende linje dog kun afviklet med et array med kun et enkelt element. Det samme gjaldt for de første mange der var inde på testen efter den feature var blevet introduceret. Og derfor blev det ikke umiddelbart opdaget at sorteringen ikke virkede.
Det der skete ved den første person som havde to forskellige IPv6 adresser med samme embeddede MAC adresser var følgende. De første to array indgange var udfyldt med korrekte MAC adresser, det fylder i alt 12 bytes. Resten af arrayet var aldrig blevet skrevet til, så det indeholdt nuller, som operativsystemet havde skrevet ved allokering.
Så blev arrayet sorteret, men fejlagtigt var størrelsen på hver indgang angivet som 16 bytes. Så sammenligningen kigger på de første 16 bytes (som starter med 2 MAC adresser) og de næste 16 bytes (som alle var nul). Da nullerne var mindre blev de flyttet først, og dermed var de 2 array indgange sorteret.
Den efterfølgende kode kiggede på de første 12 bytes og konstaterede at der kun var en enkelt MAC adresse, og den forekom to gange. Derfor udskrev den adressen 00:00:00:00:00:00. (Resten af linjen med teksten XEROX CORPORATION ville have været korrekt for en MAC adresse startende med 00:00:00).
Nogen har måske bemærket at det sidste par timer har testen været nede. Jeg er 99% sikker på at årsagen er en hardware fejl. Men her er i hvert fald en beskrivelse af symptomerne, så kan I selv vurdere om i er enige i, at det er en hardware fejl.
Da jeg først ankom hvor serveren er placeret tændte jeg skærmen og der var sort skærm. Det er der ikke noget usædvanligt i, den går automatisk i sort skærm, hvis ikke der trykkes på tastaturet i et minut. Men da jeg trykkede på tastaturet skete der intet.
Da caps lock dioden ikke skiftede, når man trykkede på caps lock tasten og serveren overhovedet ikke reagerede på netværkstrafik på de to interfaces jeg testede gættede jeg på at kernen var gået ned, så jeg trykkede på reset knappen.
Da var det så at jeg konstaterede, at computeren heller ikke reagerede ved tryk på reset knappen. Så jeg slukkede og tændte igen. Serveren startede fint op indtil den skulle aktivere første netkort, så rebootede den spontant. Det skete to gange. Så prøvede jeg netboot. Også ved netboot rebootede serveren spontant så snart den gik i gang med at bruge netkortet.
Jeg vurderede at den måske blev for varm, så jeg slukkede, fjernede noget støv fra nogen af blæserne og tændte igen. Så kunne BIOS ikke engang komme i gang. Det lød som om der var noget mekanisk der ikke kunne komme igang, men jeg kunne ikke vurdere præcist hvor lyden kom fra, men alle blæserne kørte.
Jeg fjernede strømmen fra alle diskene. Så kunne den starte BIOS igen. Da den ingen diske fandt prøvede den at netboote og rebootede igen spontant.
Nu ved jeg bare ikke hvor jeg skal gætte på at fejlen ligger. Er det strømforsyningen eller bundkortet der er deffekt.
Jeg har selvfølgelig backup af de vigtige data fra serveren, så jeg skal nok få testen op igen. Testen er dog afhængig af et par interne design detaljer i min IPv6 stak, og da der lige er en enkelt algoritmisk udfordring, har jeg ikke fået testen opdateret til at køre med den nyeste udgave af min IPv6 stak. Derfor kan jeg ikke bare flytte den over på en anden computer, da de andre kører med en nyere udgave. Så den hurtigste måde at få testen op igen er at installere en ældre udgave af stakken på en anden computer jeg kan bruge indtil jeg får testen opdateret.
Da jeg først ankom hvor serveren er placeret tændte jeg skærmen og der var sort skærm. Det er der ikke noget usædvanligt i, den går automatisk i sort skærm, hvis ikke der trykkes på tastaturet i et minut. Men da jeg trykkede på tastaturet skete der intet.
Da caps lock dioden ikke skiftede, når man trykkede på caps lock tasten og serveren overhovedet ikke reagerede på netværkstrafik på de to interfaces jeg testede gættede jeg på at kernen var gået ned, så jeg trykkede på reset knappen.
Da var det så at jeg konstaterede, at computeren heller ikke reagerede ved tryk på reset knappen. Så jeg slukkede og tændte igen. Serveren startede fint op indtil den skulle aktivere første netkort, så rebootede den spontant. Det skete to gange. Så prøvede jeg netboot. Også ved netboot rebootede serveren spontant så snart den gik i gang med at bruge netkortet.
Jeg vurderede at den måske blev for varm, så jeg slukkede, fjernede noget støv fra nogen af blæserne og tændte igen. Så kunne BIOS ikke engang komme i gang. Det lød som om der var noget mekanisk der ikke kunne komme igang, men jeg kunne ikke vurdere præcist hvor lyden kom fra, men alle blæserne kørte.
Jeg fjernede strømmen fra alle diskene. Så kunne den starte BIOS igen. Da den ingen diske fandt prøvede den at netboote og rebootede igen spontant.
Nu ved jeg bare ikke hvor jeg skal gætte på at fejlen ligger. Er det strømforsyningen eller bundkortet der er deffekt.
Jeg har selvfølgelig backup af de vigtige data fra serveren, så jeg skal nok få testen op igen. Testen er dog afhængig af et par interne design detaljer i min IPv6 stak, og da der lige er en enkelt algoritmisk udfordring, har jeg ikke fået testen opdateret til at køre med den nyeste udgave af min IPv6 stak. Derfor kan jeg ikke bare flytte den over på en anden computer, da de andre kører med en nyere udgave. Så den hurtigste måde at få testen op igen er at installere en ældre udgave af stakken på en anden computer jeg kan bruge indtil jeg får testen opdateret.
Det kan godt tyde på at det er dit raid controller der har været halvdød-ish, når det hjalp at fjerne diskene.. Har oplevet det tidligere på serveraid 8k controllere..
Den kørte software RAID. Der er ingen hardware RAID controller i maskinen. Og bemærk at selvom alle diskene var koblet fra rebootede maskinen stadigvæk, når den prøvede at netboote.didriksen86 (124) skrev:Det kan godt tyde på at det er dit raid controller der har været halvdød-ish, når det hjalp at fjerne diskene..
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund