Dear Product Manager
From google, we get to know that you focus on communication pruducts with high reputation.We are professional IP-PBX,GSM gateway manufacturer with high-quality and competitive price.
MyPBX STD V4 is the newest version that supports PSTN,GSM,VoIP trunks with FXS / FXO / PRI / BRI (ISDN) ports. It is embedded hybrid IP-PBX which caters for the small businesses.
Please feel free to contact me to get further information to open our cooperation relationship in 2011.
Thanks&Best Regards
Alex
Yeastar Technology Co.,Ltd
Web: www.yeastar.com
MSN: hqy(a)yeastar.com
Skype: Yeastar.hqy
Tel: +86 592 5503309 Ext.8026
Add: 202,No.23 Wanghai Road, 2nd Software Park, Xiamen, China
--------------------------------------------------------------------------------
# this is a 16 GB Patriot xporter XT Boost USB flash drive, lsusb claim
# 2 GB, but that is understandable
$ lsusb
Bus 001 Device 023: ID 13fe:3100 Kingston Technology Company Inc. 2 GB USB stick
# The erase block size is clearly 8 MB, page size is not clear from this:
$ sudo ./flashbench /dev/sdc -a --blocksize=1024
align 1610612736 pre 545µs on 872µs post 721µs diff 239µs
align 1073741824 pre 527µs on 811µs post 659µs diff 218µs
align 805306368 pre 547µs on 818µs post 673µs diff 208µs
align 536870912 pre 536µs on 814µs post 664µs diff 214µs
align 402653184 pre 548µs on 819µs post 666µs diff 212µs
align 268435456 pre 541µs on 822µs post 673µs diff 215µs
align 201326592 pre 548µs on 818µs post 658µs diff 215µs
align 134217728 pre 547µs on 822µs post 651µs diff 223µs
align 100663296 pre 554µs on 822µs post 654µs diff 218µs
align 67108864 pre 540µs on 823µs post 662µs diff 222µs
align 50331648 pre 528µs on 817µs post 644µs diff 231µs
align 33554432 pre 557µs on 815µs post 672µs diff 200µs
align 25165824 pre 543µs on 821µs post 680µs diff 209µs
align 16777216 pre 548µs on 822µs post 675µs diff 211µs
align 12582912 pre 666µs on 688µs post 660µs diff 25.3µs
align 8388608 pre 543µs on 819µs post 656µs diff 219µs
align 6291456 pre 658µs on 697µs post 663µs diff 36.3µs
align 4194304 pre 651µs on 697µs post 656µs diff 44.2µs
align 3145728 pre 668µs on 692µs post 672µs diff 21.7µs
align 2097152 pre 660µs on 688µs post 673µs diff 21.2µs
align 1572864 pre 664µs on 695µs post 666µs diff 30µs
align 1048576 pre 669µs on 696µs post 659µs diff 32.2µs
align 786432 pre 664µs on 697µs post 652µs diff 39.6µs
align 524288 pre 670µs on 698µs post 656µs diff 35.1µs
align 393216 pre 664µs on 697µs post 651µs diff 40µs
align 262144 pre 661µs on 696µs post 667µs diff 32.6µs
align 196608 pre 665µs on 695µs post 663µs diff 30.8µs
align 131072 pre 657µs on 680µs post 666µs diff 18.7µs
align 98304 pre 670µs on 684µs post 669µs diff 14.3µs
align 65536 pre 663µs on 684µs post 660µs diff 22.3µs
align 49152 pre 653µs on 895µs post 668µs diff 235µs
align 32768 pre 664µs on 684µs post 669µs diff 17.7µs
align 24576 pre 667µs on 685µs post 667µs diff 18.1µs
align 16384 pre 652µs on 894µs post 659µs diff 239µs
align 12288 pre 665µs on 685µs post 659µs diff 23.1µs
align 8192 pre 653µs on 681µs post 669µs diff 20.2µs
align 6144 pre 656µs on 683µs post 667µs diff 21.9µs
align 4096 pre 663µs on 676µs post 672µs diff 8.79µs
align 3072 pre 670µs on 670µs post 665µs diff 2.62µs
align 2048 pre 661µs on 677µs post 658µs diff 17.1µs
# Optimum I/O size is 64 KB, page size looks like 32 KB effective
sudo ./flashbench --erasesize=$[8*1024*1024] --open-au --open-au-nr=3 /dev/sdc --blocksize=4096
8MiB 15M/s
4MiB 14.9M/s
2MiB 14.9M/s
1MiB 15.4M/s
512KiB 15.7M/s
256KiB 13.1M/s
128KiB 13.1M/s
64KiB 16.4M/s
32KiB 10.9M/s
16KiB 3.12M/s
8KiB 1.67M/s
4KiB 861K/s
# six erase blocks is still fine
$ sudo ./flashbench --erasesize=$[8*1024*1024] --open-au --open-au-nr=6 /dev/sdc
8MiB 15.3M/s
4MiB 14.6M/s
2MiB 14.2M/s
1MiB 14.9M/s
512KiB 15.4M/s
256KiB 13.5M/s
128KiB 12.3M/s
64KiB 16M/s
32KiB 10.6M/s
16KiB 3.16M/s
# ten erase block not so, gradual decline hints at log-structured writes:
$ sudo ./flashbench --erasesize=$[8*1024*1024] --open-au --open-au-nr=10 /dev/sdc
8MiB 14.8M/s
4MiB 12.9M/s
2MiB 10.5M/s
1MiB 6.79M/s
512KiB 4.25M/s
^C
# get the stick into fast case again, by writing to it with six blocks:
$ sudo ./flashbench --erasesize=$[8*1024*1024] --open-au --open-au-nr=6 /dev/sdc --blocksize=$[4 * 1024 * 1024]
8MiB 12.8M/s
4MiB 12.6M/s
$ sudo ./flashbench --erasesize=$[8*1024*1024] --open-au --open-au-nr=6 /dev/sdc --blocksize=$[4 * 1024 * 1024]
8MiB 14.6M/s
4MiB 14.3M/s
# seven block still ok:
$ sudo ./flashbench --erasesize=$[8*1024*1024] --open-au --open-au-nr=7 /dev/sdc --blocksize=$[1 * 1024 * 1024]
8MiB 14.3M/s
4MiB 14.4M/s
2MiB 14M/s
1MiB 14.5M/s
# eight blocks ok:
$ sudo ./flashbench --erasesize=$[8*1024*1024] --open-au --open-au-nr=8 /dev/sdc --blocksize=$[32 * 1024]
8MiB 14.7M/s
4MiB 14.1M/s
2MiB 14.5M/s
1MiB 14.9M/s
512KiB 15M/s
256KiB 13.3M/s
128KiB 12M/s
64KiB 16.4M/s
32KiB 10.4M/s
# nine blocks is where we hit the wall, though 16 KB and smaller is ok:
$ sudo ./flashbench --erasesize=$[8*1024*1024] --open-au --open-au-nr=9 /dev/sdc --blocksize=$[32 * 1024]
8MiB 14.7M/s
4MiB 13.9M/s
2MiB 12.3M/s
1MiB 10M/s
512KiB 7.11M/s
256KiB 4.8M/s
128KiB 2.51M/s
64KiB 1.44M/s
32KiB 726K/s
16KiB 3.02M/s
8KiB 1.51M/s
4KiB 782K/s
# resetting the device by writing 8 blocks again:
$ sudo ./flashbench --erasesize=$[8*1024*1024] --open-au --open-au-nr=8 /dev/sdc --blocksize=$[4 * 1024 * 1024]
8MiB 14.6M/s
4MiB 14.6M/s
# trying eight blocks with random access, the device copes ok, but not
# perfect, another indication for log-structured:
$ sudo ./flashbench --erasesize=$[8*1024*1024] --open-au --open-au-nr=8 /dev/sdc --blocksize=$[4 * 1024] --random
8MiB 15M/s
4MiB 11.6M/s
2MiB 8.3M/s
1MiB 7.84M/s
512KiB 5.3M/s
256KiB 6.53M/s
128KiB 4.79M/s
64KiB 7.37M/s
32KiB 6.69M/s
16KiB 3.08M/s
8KiB 1.55M/s
4KiB 787K/s
# nine blocks random I/O: somewhat worse than 9 blocks linear, 16 KB
# blocks are still as fast as always
$ sudo ./flashbench --erasesize=$[8*1024*1024] --open-au --open-au-nr=9 /dev/sdc --blocksize=$[4 * 1024] --random
8MiB 14.6M/s
4MiB 11.3M/s
2MiB 7.05M/s
1MiB 4.74M/s
512KiB 3.21M/s
256KiB 1.8M/s
128KiB 1.13M/s
64KiB 694K/s
32KiB 376K/s
16KiB 2.96M/s
8KiB 1.45M/s
4KiB 739K/s
# Looking for FAT optimizations, nothing there:
$ sudo ./flashbench --erasesize=$[8*1024*1024] --findfat --fat-nr=4 /dev/sdc --blocksize=$[4 * 1024] --random
8MiB 15.2M/s 16.3M/s 14.3M/s 14.1M/s
4MiB 11.4M/s 11.4M/s 11.7M/s 12M/s
2MiB 8.32M/s 8.3M/s 8.32M/s 8.41M/s
1MiB 7.93M/s 7.93M/s 7.93M/s 7.89M/s
512KiB 5.34M/s 5.32M/s 5.33M/s 5.34M/s
256KiB 6.6M/s 6.51M/s 6.6M/s 6.59M/s
128KiB 4.85M/s 4.86M/s 4.85M/s 4.85M/s
64KiB 7.48M/s 7.51M/s 7.52M/s 7.48M/s
32KiB 6.79M/s 6.91M/s 6.96M/s 6.97M/s
16KiB 3.18M/s 3.19M/s 3.2M/s 3.2M/s
8KiB 1.61M/s 1.62M/s 1.62M/s 1.61M/s
4KiB 820K/s 819K/s 812K/s 818K/s
Verdict: Decent algorithm, the stick assumes random writes when accessed with 16 KB blocks
but linear writes for anything larger. Linear write performance good, even across many
erase blocks.
On Thursday 24 March 2011, Michael Monnerie wrote:
> We could speak german, I guess?
Yes, but I'd prefer to keep the discussion on the mailing list
if interesting results come up.
> On Donnerstag, 24. März 2011 Arnd Bergmann wrote:
> >
> > Are these results reproducible? It's not at all clear to me that the
> > erase size is really 4 MB, it could also be 1 MB for instance,
> > especially if your stick is from before 2010. You can rerun the
> > command with --count=100 or more, or with larger block sizes to get
> > a better feeling.
>
> # ./flashbench -a /dev/sde --blocksize=4096 --count=100
> sched_setscheduler: Operation not permitted
> align 536870912 pre 703µs on 798µs post 666µs diff 114µs
> align 268435456 pre 700µs on 753µs post 681µs diff 62.8µs
> align 134217728 pre 786µs on 783µs post 645µs diff 67.4µs
> align 67108864 pre 723µs on 772µs post 675µs diff 73.3µs
> align 33554432 pre 701µs on 762µs post 674µs diff 74.4µs
> align 16777216 pre 701µs on 741µs post 685µs diff 48.3µs
> align 8388608 pre 695µs on 749µs post 668µs diff 66.8µs
> align 4194304 pre 706µs on 791µs post 671µs diff 102µs
> align 2097152 pre 674µs on 707µs post 692µs diff 23.9µs
> align 1048576 pre 683µs on 726µs post 701µs diff 34.3µs
> align 524288 pre 671µs on 726µs post 717µs diff 32.3µs
> align 262144 pre 698µs on 713µs post 687µs diff 20.7µs
> align 131072 pre 682µs on 740µs post 704µs diff 46.9µs
> align 65536 pre 687µs on 727µs post 697µs diff 35.1µs
> align 32768 pre 712µs on 722µs post 692µs diff 19.9µs
> align 16384 pre 667µs on 699µs post 674µs diff 27.9µs
> align 8192 pre 702µs on 770µs post 686µs diff 75.8µs
Ok, this is much clearer: I'm pretty sure that it's either 4 MB or 8 MB,
based on this result. Note how all diff values below 4 MB are smaller than
all diff values above 4 MB. Something strange is going at at 4 MB, so it's
not clear whether it belongs to the upper or lower half.
> # ./flashbench -a /dev/sde --blocksize=8192 --count=50
> sched_setscheduler: Operation not permitted
> align 536870912 pre 879µs on 899µs post 858µs diff 30.9µs
> align 268435456 pre 847µs on 906µs post 842µs diff 61.1µs
> align 134217728 pre 996µs on 968µs post 836µs diff 52µs
> align 67108864 pre 811µs on 839µs post 757µs diff 55µs
> align 33554432 pre 871µs on 908µs post 847µs diff 48.7µs
> align 16777216 pre 854µs on 914µs post 818µs diff 78µs
> align 8388608 pre 851µs on 908µs post 850µs diff 58.2µs
> align 4194304 pre 892µs on 880µs post 908µs diff -20511n
> align 2097152 pre 828µs on 849µs post 885µs diff -7708ns
> align 1048576 pre 874µs on 886µs post 862µs diff 17.9µs
> align 524288 pre 852µs on 869µs post 915µs diff -15025n
> align 262144 pre 844µs on 895µs post 940µs diff 2.73µs
> align 131072 pre 848µs on 884µs post 907µs diff 6.1µs
> align 65536 pre 837µs on 857µs post 840µs diff 18µs
> align 32768 pre 831µs on 864µs post 861µs diff 17.7µs
> align 16384 pre 855µs on 841µs post 826µs diff 201ns
>
> Could it be some linux cache is in the way?
No, all I/O is done with O_DIRECT, which completely bypasses the
page cache. In theory, there could be a cache on the stick, but
that's rarely the case. The USB protocol adds some jitter here,
and for some reason you cannot use real-time scheduling, which makes
the results less accurate.
> > Another helpful indication would be the output of 'fdisk -lu
> > /dev/sde': It will show the start of the partition and the size of
> > the drive, both should be a multiple of the erase block size.
>
> # fdisk -lu /dev/sde
>
> Disk /dev/sde: 16.2 GB, 16240345088 bytes
> 255 heads, 63 sectors/track, 1974 cylinders, total 31719424 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x925df597
Ok, 16240345088 bytes is 121 times 128 MiB, so it's certainly not using
4128 KiB blocks or some other strange unit.
> Device Boot Start End Blocks Id System
> /dev/sde1 63 31712309 15856123+ 7 HPFS/NTFS/exFAT
>
> I didn't use sde1 but sde for the tests, so it shouldn't have a meaning.
> I'll change the partition to start at 2048 or whatever I find the erasesize to be.
Be careful here. The original FAT layout is typically made specifically
for this stick, so it's probably a good idea to make a backup of the first
few blocks.
> > Finally, a third way is to look at a gnuplot chart on the output of
> >
> > flashbench -s -o output.plot /dev/sde --scatter-order=10
> > --scatter-span=2 --blocksize=8192 gnuplot -p -e 'plot "output.plot"'
> >
> > On many drives, the boundaries between erase blocks show up as spikes
> > in the chart.
>
> Phew, two lines, more or less, and spikes everwhere (see attached).
Right, nothing to see here yet. It only shows the first 8 MB, so if the
spike is every 8 MB, it won't show up here. Use --scatter-order=12 to show
more. Also, the jitter from the USB protocol may hide some details,
which might get better with a larger --count= value, but that would make
the test run much longer.
It's probably good enough to assume that the size is actually 8 MB
or 4 MB, and keep going from there.
> > Also, please post the USB ID and name output from 'lsusb' for
> > reference.
>
> # lsusb -v
> Bus 001 Device 005: ID 1b1c:1a90
Ok.
> Now with 16 I got it slower, still no visible border:
>
> # ./flashbench -O --erasesize=$[4 * 1024 * 1024] --blocksize=$[64 * 1024] /dev/sde --open-au-nr=4
> sched_setscheduler: Operation not permitted
> 4MiB 7.3M/s
> 2MiB 11.2M/s
> 1MiB 15.7M/s
> 512KiB 19.2M/s
> 256KiB 14.5M/s
> 128KiB 12.8M/s
> 64KiB 18.8M/s
> # ./flashbench -O --erasesize=$[4 * 1024 * 1024] --blocksize=$[64 * 1024] /dev/sde --open-au-nr=16
> sched_setscheduler: Operation not permitted
> 4MiB 9.77M/s
> 2MiB 3.41M/s
> 1MiB 7.38M/s
> 512KiB 5.69M/s
> ^C (took too long)
If it takes too long, that's a good indication that something interesting is happening ;-)
> Seems that stick wants to hide it's internals?
Not completely unusual, but somewhat harder than most.
I've committed some updates now that might help make the --open-au results a bit clearer,
and faster.
What I would recommend now is to update to the latest git version (just
uploaded), and then try increasing numbers of --open-au-nr= with 4 MB
erasesize, until you hit the cutoff. Try the same with --random, for the
last fast one and the first slow one:
./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au-nr=5
./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au-nr=6
./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au-nr=7
...
./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au-nr=N
=> N is the number of 4 MB blocks that can not be handled
./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au-nr=(N-1) --random
./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au-nr=N --random
=> Verify that the (N-1) --random case is still fast
./flashbench -O --erasesize=$[8 * 1024 * 1024] /dev/sde --open-au-nr=((N-1)/2) --random
./flashbench -O --erasesize=$[8 * 1024 * 1024] /dev/sde --open-au-nr=(N-1) --random
./flashbench -O --erasesize=$[8 * 1024 * 1024] /dev/sde --open-au-nr=(N-1) --random
Arnd
Dear Product Manager
From google, we get to know that you focus on communication pruducts with high reputation.We are professional IP-PBX,GSM gateway manufacturer with high-quality and competitive price.
MyPBX STD V4 is the newest version that supports PSTN,GSM,VoIP trunks with FXS / FXO / PRI / BRI (ISDN) ports. It is embedded hybrid IP-PBX which caters for the small businesses.
Please feel free to contact me to get further information to open our cooperation relationship in 2011.
Thanks&Best Regards
Alex
Yeastar Technology Co.,Ltd
Web: www.yeastar.com
MSN: hqy(a)yeastar.com
Skype: Yeastar.hqy
Tel: +86 592 5503309 Ext.8026
Add: 202,No.23 Wanghai Road, 2nd Software Park, Xiamen, China
--------------------------------------------------------------------------------
Dear Sir & Madam,
Have a nice day !
This is Sam Peng from BSI (BEST SERVICES INT'L FREIGHT LTD) in China.we are as
agent of Lufthansa Cargo / LH ; Lan Chile / LAN ; Bringer Air Cargo / E6 in China.
We specialize in Air freight / Sea shipping to Brazil in China.
It's my pleasure to send the the below air price for your reference.
Shenzhen / Guangzhou / Dongguan ; China to San Paulo ; Brazil :
1) A/Freight : USD7.10/KG (more than 1000kgs)
2) Frequency : Fri
3) Airways : Emirates Skycargo Airlines / EK
4) Transit Time: 3~4days
5) Departure : from HongKong
6) Flight Route : HongKong--Dubai--San Paulo
***we can help you to pick up the goods from any city in China to Brazil***
Our Promise:
-- Closely keep in touch with you & Supplier.
-- Keep working with you in the same time as you to know all update
information for your order in time.
-- Combine the shipment from different supplier and make the combine
packing list & commercial invoice to one set original document
-- Assist you to check new supplier's company credit.
-- Ensure Cargo to be loaded at the soonest.
-- Ensure to provide best logsitics project to save your purchase cost.
-- Keep update the cargo tracking information for you.
Our Certifications:
-- IATA: International Air Transport Association.
-- NVOCC: Non Vessel Operating Common Carrier.
-- WCA: Member of World Cargo Alliance.
-- CATA: China Civil Air Transport Sales (Class A) Agency Services.
I expect you to try our services for your air cargo to Brazil. I'm sure that our
sincerely services can make you feel satisfied.Please don't hesitate to contact
with me in any time.
B. regards!
Sam Peng
Sales Dept
BEST SERVICES INTERNATIONAL FREIGHT LTD
Rm.B13-19, 10/F, Regalia Place, Jiabin Rd, Shenzhen, China.
Tel : 86-755-25904212
Fax : 86-755-25901937 / 25901911
Cell Phone : +86-13760303532
E-mail : sales4.szx(a)bsigroup.cc
MSN : sampeng8210(a)hotmail.com
Skype : sampeng821007
Website: http://www.bestservices.com.cn
IATA: 08-3 1624 CATA: ZN30165 FMC: 022856 NVOCC: MOC-NV03395
BSI Offices : Shenzhen, HongKong, Guangzhou, Shanghai, Ningbo, Xiamen,
Dongguan, Zhongshan, Jiangmen.
BSI representative offices : Qingdao, Dalian, Tianjin, Beijing, Lianyungang,
Yantai, Fuzhou, Zhuhai, Shantou, Chongqing, Chengdu and others.
All transactions are subject to the Company's Standard Trading Conditions
( copy is available upon request ), which in certain circumstances limit or
exempt the Company's liability.
I can't interpret the numbers for the AUs, can you help me?
# ./flashbench -a /dev/sde --blocksize=1024
sched_setscheduler: Operation not permitted
align 536870912 pre 745µs on 756µs post 696µs diff 36.2µs
align 268435456 pre 698µs on 882µs post 670µs diff 198µs
align 134217728 pre 722µs on 899µs post 715µs diff 180µs
align 67108864 pre 720µs on 712µs post 669µs diff 17.1µs
align 33554432 pre 750µs on 765µs post 639µs diff 70.1µs
align 16777216 pre 727µs on 777µs post 684µs diff 71.8µs
align 8388608 pre 691µs on 727µs post 646µs diff 58.3µs
align 4194304 pre 689µs on 769µs post 675µs diff 87.3µs
align 2097152 pre 697µs on 879µs post 715µs diff 173µs
align 1048576 pre 716µs on 899µs post 789µs diff 147µs
align 524288 pre 659µs on 775µs post 724µs diff 83.4µs
align 262144 pre 657µs on 735µs post 685µs diff 63.6µs
align 131072 pre 656µs on 706µs post 756µs diff -248ns
align 65536 pre 655µs on 715µs post 650µs diff 62.3µs
align 32768 pre 732µs on 792µs post 743µs diff 54.1µs
align 16384 pre 685µs on 808µs post 767µs diff 82.6µs
align 8192 pre 732µs on 764µs post 697µs diff 49.8µs
align 4096 pre 661µs on 692µs post 681µs diff 20.7µs
align 2048 pre 671µs on 657µs post 653µs diff -5465ns
# ./flashbench -O --erasesize=$[4 * 1024 * 1024] --blocksize=$[256 * 1024] /dev/sde --open-au-nr=2
sched_setscheduler: Operation not permitted
4MiB 6.69M/s
2MiB 11.1M/s
1MiB 13.2M/s
512KiB 14.4M/s
256KiB 14.6M/s
# ./flashbench -O --erasesize=$[4 * 1024 * 1024] --blocksize=$[256 * 1024] /dev/sde --open-au-nr=3
sched_setscheduler: Operation not permitted
4MiB 6.68M/s
2MiB 11.2M/s
1MiB 12.9M/s
512KiB 14.5M/s
256KiB 14.8M/s
# ./flashbench -O --erasesize=$[4 * 1024 * 1024] --blocksize=$[256 * 1024] /dev/sde --open-au-nr=4
sched_setscheduler: Operation not permitted
4MiB 6.8M/s
2MiB 10.9M/s
1MiB 13M/s
512KiB 14.4M/s
256KiB 14.6M/s
# ./flashbench -O --erasesize=$[4 * 1024 * 1024] --blocksize=$[256 * 1024] /dev/sde --open-au-nr=6
sched_setscheduler: Operation not permitted
4MiB 7.45M/s
2MiB 9.24M/s
1MiB 16.4M/s
512KiB 17.4M/s
256KiB 7.98M/s
--
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc
it-management Internet Services: Protéger
http://proteger.at [gesprochen: Prot-e-schee]
Tel: +43 660 / 415 6531
// ****** Radiointerview zum Thema Spam ******
// http://www.it-podcast.at/archiv.html#podcast-100716
//
// Haus zu verkaufen: http://zmi.at/langegg/
Dear Sir or Madam,
Glad to hear that you're on the market for mobile phone. We, Wei Wan
Technology are a professional manufacturer for mobile phone.
Dual Sim card and Triple Sim card etc
Please contact me if any questions.
Sincerely hope to find a way to cooperate with your esteemed company!
Thanks & best regards
Juce
E-mail: elink(a)vip.188.com
Factory Address: 5/F, Building 21, ChenTian Industrial Park, BaoTian 2nd
Road, Xixiang Town, Bao'anDistrict, Shenzhen, GuangDong Province, China
