Journal 174 Mbits/s en download et 18Mbits/s en émission : le futur de FREE
25
nov.
2005
C'est le débit en préparation pour les abonnés de Free : http://www.iliad.fr/actualites/Cp_251105.pdf. Ce n'est plus de l'ADSL2+, mais du F-ADSL. A noter qu' à 1800 mètres du NRA, le débit atteint est de 120 Mbits/s
# Mouais,
Posté par lezardbreton . Évalué à 8.
# Il n'y a qu'une page à lire
Posté par Boa Treize (site web personnel) . Évalué à 9.
[^] # Re: Il n'y a qu'une page à lire
Posté par lezardbreton . Évalué à 2.
[^] # Re: Il n'y a qu'une page à lire
Posté par Mr F . Évalué à 4.
Free parle dans son communiquer de l'utilisation de la technologie ADSL2+, hors cette technologie ne permet pas de faire plus de 20Mb. C'est comme l'ADSL qui ne permet pas de faire plus de 8 Mb. L'idée de Free est d'utiliser plusieurs paires de cuivre et de les coupler afin d'augmenter le débit. L'appelation de cette technique est, d'après Free, le F-ADSL. Il faut donc bien une dixaine de ligne FT, environs, pour atteindre ce débit.
[^] # Re: Il n'y a qu'une page à lire
Posté par Antoine Reversat . Évalué à 5.
[^] # Re: Il n'y a qu'une page à lire
Posté par kowalsky . Évalué à 5.
gigogne, 8 dans un RJ45 que ft te livre une continuité
jusqu'au central sur 8 fil.
Des le niveau des têtes ptt de la zones ou du batiment, une ligne RTC = une paire.
[^] # Re: Il n'y a qu'une page à lire
Posté par dab . Évalué à 1.
Une petite version en français, s'il vous plait ?
[^] # Re: Il n'y a qu'une page à lire
Posté par Pior . Évalué à 4.
Au passage je me demande bien à quoi sert le 3eme fils présent sur les cables de téléphone aérien dans la rue. Juste une meilleur résistance mécanique ?
[^] # Re: Il n'y a qu'une page à lire
Posté par legranblon (site web personnel) . Évalué à 3.
[^] # Re: Il n'y a qu'une page à lire
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 9.
[^] # Re: Il n'y a qu'une page à lire
Posté par TImaniac (site web personnel) . Évalué à 1.
NOn ils disent utilisé l' F-ADSL basé sur l'ADSL2+. L'ADSL2+ est lui même basé sur l'ADSL et pourtant l'ADSL2+ n'est pas une multiplication des lignes téléphoniques.
JE ne sais pas du tout à quoi correspond ce F-ADSL mais prétendre qu'ils n'ont fait que multiplier les lignes téléphoniques ca n'est fondé sur rien du tout.
[^] # Re: Il n'y a qu'une page à lire
Posté par Christophe Merlet (site web personnel) . Évalué à 8.
Il suffit pourtant de lire !
Le sous-titre du communiqué de presse de Free parle clairement de couplage de lignes. Il suffit alors de sortir son dictionnaire quand on ne comprends pas tous les mots et on peut alors légitimement en conclure que Free parle bien d'utiliser plusieurs lignes téléphoniques pour atteindre de tel débits.
On comprends alors pourquoi free n'envisage pas de commercialisation de ce service !
Comme les dslam de free tourne sous linux, il leur a suffit de compiler le module bonding pour arriver a pondre cet "exploit technologique".
Moi je propose à free de ranger au placard leur ingénieur en pipeau-marketing et d'en sortir un autre qui va faire des freebox compatible SDSL. Perso je préfèrerait avoir un débit quasi symétrique plutot que fortement asymétrique.
[^] # Re: Il n'y a qu'une page à lire
Posté par M . Évalué à 4.
Moi je propose à free de ranger au placard leur ingénieur en pipeau-marketing et d'en sortir un autre qui va faire des freebox compatible SDSL. Perso je préfèrerait avoir un débit quasi symétrique plutot que fortement asymétrique.
Oui, mais ca les actionnaires s'en foutent ainsi que Mr tout le monde...
[^] # Re: Il n'y a qu'une page à lire
Posté par Fabimaru (site web personnel) . Évalué à 4.
Monsieur tout le monde voit sa vie bouleversée d'avoir un 20Mb plutôt que du 10 ? Permet moi d'émettre des doutes.
[^] # Re: Il n'y a qu'une page à lire
Posté par Dr BG . Évalué à 4.
[^] # Re: Il n'y a qu'une page à lire
Posté par Troy McClure (site web personnel) . Évalué à 8.
[^] # Re: Il n'y a qu'une page à lire
Posté par Fabimaru (site web personnel) . Évalué à 9.
[^] # Re: Il n'y a qu'une page à lire
Posté par TImaniac (site web personnel) . Évalué à 1.
Le sous-titre du communiqué de presse de Free parle clairement de couplage de lignes.
Effectivement je sais pas lire désolé :)
[^] # Re: Il n'y a qu'une page à lire
Posté par Ontologia (site web personnel) . Évalué à -1.
S'il s'agit bieng du protocole ATM, ça pourrait peut être s'expliquer par le fait que celui-ci est beaucoup plus performant (et plus cher) qu'IP. C'est un protocole à commutation de cellule.
Peut être que ça explique quelque chose ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Il n'y a qu'une page à lire
Posté par Mr F . Évalué à 3.
C'est tout simplement fondé sur le fait que la paire de cuivre ne permet pas, pour l'instant, de tel débit. Et même si Free posséde beaucoup de compétence, je doute qu'il soit le seul à "découvrir" comment révolutionner brutalement le débit sur ligne téléphonique (avec tous les effets de bord que l'utilisation de hautes fréquences posent).
De surcroit, la démodulation de l'adsl est en dur dans les DSLAM Free. S'il n'y a donc pas de changement de DSLAM c'est que cela reste de l'ADSL2+.
Bref, tout cela est fondé sur des connaissances que je te trouve bien prompt à remettre en cause pour des raisons et des arguments non avancés...
Sur un autre registre, cette technologie pourrait permettre de mutualiser le débit Internet d'un immeuble, ce qui pourrait être interessant.
# petit calcul
Posté par plagiats . Évalué à 4.
174 Mbits/s = 21,75 Mo/s
Un CD de 650 mo se télécharge alors en ... 30 secondes.
Troll ! En moins de 5 minutes on pourra télécharger et graver les 5 isos de la SuSE.
[^] # Re: petit calcul
Posté par Yann012 . Évalué à 3.
Donc bon télécharger vite c'est bien mais faut-il encore pouvoir écrire assez vite sur les supports locaux...
[^] # Re: petit calcul
Posté par ʭ ☯ . Évalué à 10.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: petit calcul
Posté par Anonyme . Évalué à 1.
J'ai des disques durs de 120 Go sur cette machine, tous les deux en UDMA100, et moi aussi j'ai remarqué que 10 Mo/s (donc 80 Mb/s) était une valeur quasi maximale, et qu'en moyenne, ça avait plutôt tendance à osciller entre 5 et 7 Mo/s.
Sur la machine d'à côté, j'ai un disque de 80 Go UDMA100 et c'est le même topo (marque de disque dur et matériel PC différents de l'autre machine), donc j'en déduit que ces valeurs sont « normales ».
Ou alors, t'as un disque dur de compet dopé aux hormones :-)
[^] # Re: petit calcul
Posté par jerome (site web personnel) . Évalué à 0.
[^] # Re: petit calcul
Posté par Nicolas Bernard (site web personnel) . Évalué à 3.
[^] # Re: petit calcul
Posté par jerome (site web personnel) . Évalué à 0.
Le RAID1, mirroring, c'est censé améliorer, quoique pas de manière fulgurante non plus, les performances en lecture.
[^] # Re: petit calcul
Posté par briaeros007 . Évalué à 3.
La lecture ne sera jamais que min (lecture_disques_i) où disques_i symbolise chacun des disques de ton raid.
[^] # Re: petit calcul
Posté par x0ra . Évalué à 9.
ps: je parle en octets, pas en bits ...
[^] # Re: petit calcul
Posté par Pascal Terjan (site web personnel) . Évalué à 5.
[pterjan@cmoi 6]$ time ./test.sh
400+0 enregistrements lus.
400+0 enregistrements écrits.
0.02user 5.08system 0:11.14elapsed 45%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+853minor)pagefaults 0swaps
[pterjan@cmoi 6]$ cat test.sh
dd if=/dev/zero of=test bs=1M count=400
sync
[pterjan@cmoi 6]$ ll -h test
-rw-rw-r-- 1 pterjan pterjan 400M nov 26 01:00 test
Ca fait 36 Mo/s ça ou j'hallucine ?
C'est sur un disque de 160Go en UDMA100.
[^] # Re: petit calcul
Posté par Anonyme . Évalué à 2.
Jusqu'à maintenant, j'ai fait confiance aux fenêtres de copie/déplacement de KDE.
Cela dit...
[Pap@schtroumpf]$ time ./test.sh
400+0 enregistrements lus.
400+0 enregistrements écrits.
0.00user 2.57system 0:37.66elapsed 6%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+790minor)pagefaults 0swaps
Ben moi ça fait bien 10 Mo/s, et c'est un disque dur 120 Go UDMA100
[root@schtroumpf]# hdparm -i /dev/hda
/dev/hda:
Model=IC35L120AVV207-0, FwRev=V24OA63A, SerialNo=VNVD03G4G3V21G
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=52
BuffType=DualPortCache, BuffSize=1821kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=241254720
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: ATA/ATAPI-6 T13 1410D revision 3a:
* signifies the current active mode
Et sinon :
root@schtroumpf]# hdparm -tT /dev/hda
/dev/hda:
Timing cached reads: 1224 MB in 2.00 seconds = 611.18 MB/sec
Timing buffered disk reads: 130 MB in 3.00 seconds = 43.28 MB/sec
La machine est un Athlon XP 2200+ avec 768 Mo de DDR, avec une Mandriva 2006 tout fraichement installée par défaut, et j'obtiens des résultats approchants sur une autre machine dotée d'un Pentium 4 à 2 GHz et de 256 Mo de mémoire.
Effectivement, j'ai toujours trouvé les accès disques particulièrement lents sous Linux, en comparaison de ce que j'obtenais sous Windows.
[^] # Re: petit calcul
Posté par Raoul Volfoni (site web personnel) . Évalué à 3.
C'est plutot un hdparm -v qui serait intéressant car ton disque n'a pas l'air d'être bien configuré. Sur un disque Maxtor de 120 Go j'obtiens 44 Mo/s en écriture ce qui est dans la norme des disques IDE d'aujourd'hui. Ceci dit il est important de savoir où se trouve physiquement la partition (qd on peut) car la vitesse d'écriture sur les cylindres intérieurs n'est évidement pas la même que sur ceux du bord du disque. C'est pour celà qu'un bon DBA partitionne toujours ses disques lui-même après avoir correctement défini les lun.
Pour info:
Marge ~ # hdparm -v /dev/hda
/dev/hda:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 19929/255/63, sectors = 163928604672, start = 0
[^] # Re: petit calcul
Posté par Raoul Volfoni (site web personnel) . Évalué à 2.
[^] # Re: petit calcul
Posté par Anonyme . Évalué à 2.
Hop :
[root@schtroumpf]# hdparm -v /dev/hda
/dev/hda:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 16383/255/63, sectors = 241254720, start = 0
J'ai un deuxième disque dur 120 Go dans cette machine, identique au premier, et j'obtiens :
[root@schtroumpf]# hdparm -v /dev/hdb
/dev/hdb:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 65535/16/63, sectors = 241254720, start = 0
Ça me semble pourtant être bien configuré, non ?
[^] # Re: petit calcul
Posté par Raoul Volfoni (site web personnel) . Évalué à 3.
A 1ère vue oui. Mais il reste 2 ou 3 choses à vérifier car tu ne m'oteras pas l'idée que tes résultats ne sont pas normaux:
- diminue le nombre de secteurs lus d'avance à une valeur plus raisonnable: hdparm -m 16 /dev/hda (je ne crois pas que cela ait une influence sur l'écriture mais sait-on jamais)
- pendant que j'y pense, utilises-tu bien une nappe 80 broches?
- regardes aussi du coté de l'acoustic management et de l'APM:
hdparm -I /dev/hda
Finalement il te restes à tester la bonne santé de ton disque avec smartctl, car s'il y a beaucoup de secteurs défectueux, cela peut expliquer ton résultat:
smartctl -a /dev/hda puis smartctl -H /dev/hda
[^] # Re: petit calcul
Posté par Anonyme . Évalué à 3.
Il me semble que multcount était déjà à 16 (cf commentaire au-dessus), cela dit :
# hdparm -m 16 /dev/hda
/dev/hda:
setting multcount to 16
multcount = 16 (on)
Oui, c'est la première chose que j'ai vérifié, et je l'ai même changée par une neuve :-)
Je mets en gras 2 trucs qui m'ont semblé bizarre (excepté la commande) :
# hdparm -I /dev/hda
/dev/hda:
ATA device, with non-removable media
powers-up in standby; SET FEATURES subcmd spins-up.
Model Number: IC35L120AVV207-0
Serial Number: VNVD03G4G3V21G
Firmware Revision: V24OA63A
Standards:
Used: ATA/ATAPI-6 T13 1410D revision 3a
Supported: 6 5 4 3
Configuration:
Logical max current
cylinders 16383 65535
heads 16 1
sectors/track 63 63
--
CHS current addressable sectors: 4128705
LBA user addressable sectors: 241254720
LBA48 user addressable sectors: 241254720
device size with M = 1024*1024: 117800 MBytes
device size with M = 1000*1000: 123522 MBytes (123 GB)
Capabilities:
LBA, IORDY(can be disabled)
bytes avail on r/w long: 52 Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Advanced power management level: unknown setting (0x0000)
Recommended acoustic management value: 128, current value: 254
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=240ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* NOP cmd
* READ BUFFER cmd
* WRITE BUFFER cmd
* Host Protected Area feature set
Release interrupt
* Look-ahead
* Write cache
* Power Management feature set
Security Mode feature set
* SMART feature set
* FLUSH CACHE EXT command
* Mandatory FLUSH CACHE command
* Device Configuration Overlay feature set
* 48-bit Address feature set
* Automatic Acoustic Management feature set
SET MAX security extension
Address Offset Reserved Area Boot
SET FEATURES subcommand required to spinup after power up
Power-Up In Standby feature set
Advanced Power Management feature set
* READ/WRITE DMA QUEUED
* General Purpose Logging feature set
* SMART self-test
* SMART error logging
Security:
Master password revision code = 65534
supported
not enabled
not locked
not frozen
not expired: security count
not supported: enhanced erase
60min for SECURITY ERASE UNIT.
HW reset results:
CBLID- above Vih
Device num = 0 determined by the jumper
Checksum: correct
C'est un peu long, mais je colle tout :
# smartctl -a /dev/hda
smartctl version 5.33 [i586-mandriva-linux-gnu] Copyright (C) 2002-4 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF INFORMATION SECTION ===
Device Model: IC35L120AVV207-0
Serial Number: VNVD03G4G3V21G
Firmware Version: V24OA63A
User Capacity: 123,522,416,640 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 6
ATA Standard is: ATA/ATAPI-6 T13 1410D revision 3a
Local Time is: Sun Nov 27 17:43:39 2005 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x84) Offline data collection activity
was suspended by an interrupting command from host.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (2855) seconds.
Offline data collection
capabilities: (0x1b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
No Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 48) minutes.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000b 094 094 060 Pre-fail Always - 196630
2 Throughput_Performance 0x0005 100 100 050 Pre-fail Offline - 0
3 Spin_Up_Time 0x0007 105 105 024 Pre-fail Always - 263 (Average 259)
4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 1548
5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 1
7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0
8 Seek_Time_Performance 0x0005 123 123 020 Pre-fail Offline - 37
9 Power_On_Hours 0x0012 098 098 000 Old_age Always - 20309
10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 1526
192 Power-Off_Retract_Count 0x0032 099 099 050 Old_age Always - 2084
193 Load_Cycle_Count 0x0012 099 099 050 Old_age Always - 2084
194 Temperature_Celsius 0x0002 110 110 000 Old_age Always - 50 (Lifetime Min/Max 17/65)
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 1
197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Interrupted (host reset) 10% 20286 -
# 2 Extended offline Interrupted (host reset) 10% 20176 -
# 3 Extended offline Completed without error 00% 20056 -
# 4 Extended offline Completed without error 00% 19815 -
# 5 Extended offline Completed without error 00% 19815 -
# 6 Extended offline Completed without error 00% 19699 -
# 7 Extended offline Completed without error 00% 19440 -
# 8 Extended offline Completed without error 00% 19285 -
# 9 Extended offline Completed without error 00% 19042 -
#10 Extended offline Completed without error 00% 18792 -
#11 Extended offline Completed without error 00% 18303 -
#12 Extended offline Completed without error 00% 18162 -
#13 Extended offline Completed without error 00% 17889 -
#14 Extended offline Completed without error 00% 17610 -
#15 Extended offline Completed without error 00% 17355 -
#16 Extended offline Completed without error 00% 17227 -
#17 Extended offline Completed without error 00% 17066 -
#18 Extended offline Completed without error 00% 16770 -
#19 Extended offline Completed without error 00% 16639 -
#20 Extended offline Completed without error 00% 16497 -
#21 Extended offline Completed without error 00% 16354 -
Device does not support Selective Self Tests/Logging
# smartctl -H /dev/hda
smartctl version 5.33 [i586-mandriva-linux-gnu] Copyright (C) 2002-4 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
[^] # Re: petit calcul
Posté par Raoul Volfoni (site web personnel) . Évalué à 2.
[^] # HS peut-être, mais interessant quand même.
Posté par Beurt . Évalué à 2.
[^] # Re: HS peut-être, mais interessant quand même.
Posté par Raoul Volfoni (site web personnel) . Évalué à 2.
> # hdparm -m 16 /dev/hda
J'ma complètement gouru c'est # hdparm -a 8 /dev/hda que je voulais dire. Ceci dit comme tu n'as que 2Mo de cache, il faut tester pour voir le meilleur résultat. Mais 256 secteurs c'est AMHA beaucoup trop.
> Model Number: IC35L120AVV207-0
Un Deskstar d'IBM encore en fonctionnement??? Tous ceux que j'ai eu (5 ou 6) m'ont laché les uns après les autres. Plus aucun n'est sous garantie. :-( T'as de bons backups au moins?
> cylinders 16383 65535
> heads 16 1
Ca c'est normal c'est une traduction logique faite par le Bios, ça date d'une époque où les concepteurs de Bios n'imaginaient pas des disques de la taille de ceux que nous avons maintenant. (INT 13H si mes souvenir sont bons)
> sectors/track 63 63
Là par contre je ne comprend pas trop pourquoi tu n'as pas 255 pistes. Essayes de faire une reconnaissance de ton disque par le Bios pour voir.
> Recommended acoustic management value: 128, current value: 254
Ton disque devrait être assez bruyant mais au top de ses perfs!?! En pratique ce paramètre n'a pas toujours l'effet escompté. Passes-le à 128 si tu veux essayer: hdparm -M 128 /dev/hda
> Raw_Read_Error_Rate 0x000b 094 094 060 Pre-fail Always - 196630
J'ai la flemme d'aller chercher mes docs IBM, mais ça ne me semble pas tout à fait normal un tel taux d'erreur...
Bon je suis un peu crevé alors mon dernier conseil sera de vérifier que ton driver est bien celui qui correspond à ton contrôleur. J'ai déjà vu quelques configs à la peine à cause d'un driver inadapté.
Bon courage.
[^] # Re: petit calcul
Posté par Anonyme . Évalué à 2.
[^] # Re: petit calcul
Posté par Raoul Volfoni (site web personnel) . Évalué à 2.
smartctl -t long /dev/hda
Ensuite regardes les résultats avec smartctl -a /dev/hda pour voir si tout va bien.
[^] # Re: petit calcul
Posté par Anonyme . Évalué à 2.
Et un smartctl -a /dev/hda me rajoute seulement une ligne # 1 Extended offline Completed without error 00%, le reste étant inchangé.
Je l'ai fait aussi, mais je ne vois pas de différence notable pour l'instant.
Je n'ai encore vu aucun 180GXP en retour SAV (contrairement aux 60 GXP, en effet). ;-)
À noter qu'il y a quelques semaines de cela, j'ai testé ce disque avec un Windows dessus, et les débits étaient vraiment normaux (c'est à dire bons).
Il est bien reconnu par le Bios apparemment.
Je me demande si ce n'est pas lié à aMule ce problème. Je n'ai pas lancé aMule depuis 3 jours, et le taux est passé à 95, puis 96, et maintenant 98 ! :-)
[^] # Re: petit calcul
Posté par lcld . Évalué à 1.
On a vite fait d'être alarmiste quand on parle d'IBM Desktar.
Je ne connais rien de la fiabilité des 180 GXP, mais 20000h, c'est pas mal.
Je lis bien ? Il a déjà atteint 65°C ??
Ah... la surface du disque n'est peut-être pas nickel.
Après m'être battu avec un disque bourré de secteurs de défecteux que je voulais réutiliser, j'en ai déduit que la vitesse de lecture/écriture peut diminuer si la surface est "fragile". Le disque dur en question (80 Go) n'a aucun secteur défectueux/relogé dans la première moitié, et pourtant le débit est parfois irrégulier et, en moyenne, réduit de moitié sur plusieurs centaines de Mo (et remonte ensuite à un débit normal). Si je traçait une courbe, je n'aurais rien qui ressemblerait à ce qu'on voit d'habitude. J'imagine qu'avant d'être inutilisable (ou marqué comme tel), un secteur demande plus de temps à être lu/écrit.
Avec ton disque, en lecture, tu dois avoir du 26 Mo/s minimum, et près de 55 au début du disque.
A part ça, je suis surpris que personne n'ai parlé de fragmentation.
[^] # Re: petit calcul
Posté par Anonyme . Évalué à 2.
Les 180GXP avaient corrigé le tir si j'en crois les stats de retour SAV :-)
Le problème des 60 GXP, c'est qu'ils n'étaient prévus que pour fonctionner 333 heures par mois (recommandation IBM). Les 180 GXP ont largement corrigé le tir (classés meilleurs de leur catégorie à l'époque) et sont prévus pour du 24/7, et 20.000 heures, ce n'est *rien* en comparaison de la MTBF théorique d'un tel disque dur (entre 300.000 et 1,2 millions d'heures).
[^] # Re: petit calcul
Posté par Anonyme . Évalué à 2.
C'est fort possible, vu les température qu'il a fait ici lors de la canicule :-)
Je me demande si l'utilisation d'aMule conjointement au fait que le disque était régulièrement « ras-la-gueule » n'aurait pas induit une certaine fragmentation.
Je suis en train de vider le disque pour réinstaller ma Cooker de toutes façons, donc je serais vite fixé. :-)
[^] # Re: petit calcul
Posté par fredix . Évalué à 10.
[^] # Re: petit calcul
Posté par Arnaud (site web personnel) . Évalué à 10.
# Mouaip ...
Posté par Maillequeule . Évalué à 6.
Ceci dit le but recherché est atteint : des centaines de gens vont coller le lien dans des forums ...
M
[^] # Re: Mouaip ...
Posté par Cereal Killer . Évalué à 2.
Cecis dis ... je suis censé avoir 20 Mo (300 mètre de mon DSLAM), mais 1) j'en ai que la moitié sans aucune raison apparente ... 2) je vois pas trop quel serveurs seront capable de fournir autant de débit, ni pourquoi ! à la limite pour les MAJ debian depuis leurs ftp. et 3) c'est bientot nos disques dur qu'il va falloir penser booster un peu :)
[^] # Re: Mouaip ...
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
[^] # Re: Mouaip ...
Posté par Prosper . Évalué à 7.
Et a vu de nez 7 ou 8 lignes telephoniques a faire venir chez toi pour que cette techno fonctionne ... ca a un cout aussi.
Cecis dis ... je suis censé avoir 20 Mo (300 mètre de mon DSLAM), mais 1) j'en ai que la moitié sans aucune raison apparente ... 2) je vois pas trop quel serveurs seront capable de fournir autant de débit, ni pourquoi ! à la limite pour les MAJ debian depuis leurs ftp. et 3) c'est bientot nos disques dur qu'il va falloir penser booster un peu :)
L augmentation de débit elle n est pas pour faire du ftp mais de la VOD , de la TVHD , ou encore de la visio HD....
[^] # Re: Mouaip ...
Posté par Maillequeule . Évalué à 4.
(la fibre aussi on se demande qui va la financer d'ailleurs, mais c'est un autre problème)
M
[^] # Re: Mouaip ...
Posté par Mr F . Évalué à 2.
Il ne faut pas croire que la fibre peut tout faire passer...
[^] # Re: Mouaip ...
Posté par amadeus029 . Évalué à 9.
ils proposent 100 megas dans les deux sens, avec débit garanti de 20 megas. pour l'offre de base.
Avec télévision (dont VOD) et telephone pour environs 50 euros par mois.
Mon meilleur ami est installé la semaine prochaine, je vous donne des nouvelles si vous voulez.
# PAS BIEN
Posté par Uld (site web personnel) . Évalué à 4.
Bouuuuh, en prison les vilains pirates!
[^] # Re: PAS BIEN
Posté par x0ra . Évalué à 6.
# Cout...?
Posté par kowalsky . Évalué à 3.
ne pourrais pas concurencer les interlans et autre LL.
Ils suffit de monter les vpn qui vont bien, et on a une
liaison fiable.
Si une des 10 lignes tombe en panne, le debit
ne perd que 10%...
Perso je pense que ce genre d'offre ne verra jamais
le jour, ou pas pour les particulier, en plus
c'est un peu du bricolage...
[^] # Re: Cout...?
Posté par M . Évalué à 5.
ne perd que 10%...
Bravo tu viens de trouver à quoi servait le bonding.
Au passage j'espere que free à trouvé des techniques permettant de faire passer plus de flux dans leur x lignes telephoniques que x fois ce que l'on peut faire passer dans une.
Sinon le fait qu'on peut doubler le debit d'un flux en doublant la capacité de transport c'est pas nouveau...
PS : ca me rappele que sur le reseau numerique de FT (rnis ???) il y avait le choix en 64Kb/s ou 128Kb/s (obtenu par conquetenation de 2 lignes).
Bref, ca m'a l'air plus marketing qu'autre chose....
[^] # Re: Cout...?
Posté par Ecran Plat (site web personnel) . Évalué à 1.
Bref, ca m'a l'air plus marketing qu'autre chose....
heum le rnis c'est deux cannaux à 64kb/s et un de signalisation a 16kb/s. Sur
une paire cuivre.
En rnis donc on passe deux communications en même temps sur la même ligne.
Saviez-vous que en Suisse on peut avoir l'adsl sur une ligne rnis (isdn) sans problème, mais attention les modems sont pas identique (je l'ai appris a mes dépend en voulant brancher un routeur adsl analogique sur une ligne rnis adsl, ben ca marche pas et pire ca fout en bas toute la ligne (le nt paume la connexion)). Le pire a l'époque rien de permettait de les différencier.
[^] # Re: Cout...?
Posté par serge_kara . Évalué à 0.
Pour ce que je m'en rappelle, le debit tournait dans les 7-8Ko/s voire 10 les jours de fete. Le gros avantage etant de conserver les 2 "analogiques" disponible a cote.
Et on pouvait doubler ce debit en prenant une deuxieme ligne numeris, et en bouffant deux fois plus de forfait chez le fai (donc en pratique, pas interessant).
[^] # Re: Cout...?
Posté par Matthieu . Évalué à 9.
Donc si une pelleteuse creuse trop près de ta ligne, elle va tout casser.
Si tu as un problème d'équipement genre dslam, tu as de très forte chance (ou malchance) que ça affecte toutes tes lignes.
C'est mon humble avis.
[^] # Re: Cout...?
Posté par kowalsky . Évalué à 2.
On en rigole, mais a mon boulot c'est ce nqui se fait pour les interlan
et autre, tout dois etre certifier "chemin connu"...!
[^] # Re: Cout...?
Posté par Matthieu . Évalué à 5.
# Communication à sens unique
Posté par WH (site web personnel) . Évalué à 1.
Ce problème ne touche a priori que des non-dégroupés dont l'adresse IP est en 82.65.x.x (et encore, d'autres plages sont touchées) et ne permet pas de surfer dans des conditions correctes, sans parler des Newsgroups (binaires ou autres), NG qui avaient déjà été bridés il y a environ un mois à 10 ko/connection sans aucune information préalable.
On peut évidemment passer par le proxy de Free dans le cadre du http (voire de MSN pour ceux qui en font usage), mais rien pour les joueurs on-line ou pour le FTP. Le téléphone "illimité" ne fonctionne bien évidemment pas.
A noter que ces débits ridicules ne se font pas sentir sur les sites hébergés par Free (le test de débit de Free http://adsl.free.fr/comptes/testdebit.html ne montre aucun souci par exemple) alors qu'une des raisons avancées pour ce problème est que celà vient de France Télécom qui ne fournit pas l'infrastructure nécessaire au-niveau des DSLAM.
Passons sur la hotline qui vous tient la jambe pendant une heure pour tout vous faire tester/réinstaller quand elle ne vous demande pas de voir avec France Telecom et vous comprendrez que beaucoup d'abonnés soient exaspérés, si l'on ajoute que ces problèmes durent pour certains depuis Août. A noter que certaines personnes ayant un abonnement chez un autre provider en plus de Free n'éprouvent aucunes difficultés avec les concurrents.
Tout celà pour dire que les effets d'annonce pour caresser les actionnaires dans le sens du poil, chez Free on sait faire, mais que pour indiquer les causes exactes du problème ou un délai de résolution, c'est nettement plus difficile.
Je sais, je sais, il n'y a pas de débit garanti, mais bon... Allez, je vous laisse, il faut que je retrouve mon U.S. Robotics V92.
# Bravo ...
Posté par Jérôme (site web personnel) . Évalué à 3.
http://www.clubic.com/actualite-29530-le-futur-de-l-adsl2-le(...)
:)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.