search for: 64k

Hi, Created a zpool with 64k recordsize and enabled dedupe on it. zpool create -O recordsize=64k TestPool device1 zfs set dedup=on TestPool I copied files onto this pool over nfs from a windows client. Here is the output of zpool list Prompt:~# zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT Test...

...create: gv0: success: please start the volume to access data # gluster volume start gv0 volume start: gv0: success Mount: # mkdir /mnt/gv0 # mount -t glusterfs [local-ip]:/gv0 /mnt/gv0 WARNING: getfattr not found, certain checks will be skipped.. Create file: # openssl rand 65536 > /mnt/gv0/64K # md5sum /mnt/gv0/64K ca53c9c1b6cd78f59a91cd1b0b866ed9 /mnt/gv0/64K Umount and down the volume: # umount /mnt/gv0 # gluster volume stop gv0 Stopping volume will make its data inaccessible. Do you want to continue? (y/n) y volume stop: gv0: success Check data on bricks: # md5sum /root/data[012]/...

...s and plays .opus files over the network. I am using the C# PInvoke wrapper OpusFileSharp, which calls into libopusfile and passes callbacks for read, seek, and tell. I want to enable seeking via the seek callback by not returning -1, but I find that as soon as I do libopusfile requests the last 64K of the .opus file, probably so it can calculate the duration. My program already knows the duration of each .opus file, so I would rather not have libopusfile download an extra 64K of every .opus file to discover it. I've read your FAQ here: https://wiki.xiph.org/index.php?title=OpusFAQ&amp...

I am not sure what the problems are and the reasons for the basic 64K modems used in VOIP are. I understand the compressed codecs that get the bandwidth down to 20-30 K. And perhaps the 64K units give much better potential audio than you would get on a normal POTS line. But, as phone circuits VOIP/SIP doesn't seem to perform as well as plane old phones. Multi...

Hi All, We are using MAX TNT to for some T1 PRI interconnects. I'm seeing the voice channels connect at 56K. Does anyone have the DS0 channels connecting at 64K for voice, if so what is the parameter to select 56k or 64k channels? I'm not having any issues that I know of, just wanted to bounce this off the group for a sanity check. Thanks. JR -- JR Richardson Engineering for the Masses

Hi Friends, Something I'd like to shed some light on if possible - how is it that a single ISDN conversation only uses 64K for bidirectional communication (using ulaw, correct?), but on several occasions now have seen references to ulaw voip conversations using 64K per side of the conversation, plus packet overhead (http://www.zytrax.com/tech/protocols/voip_rates.htm - seems to be down now - plus other references)...

...-----Original Message----- From: openssh-unix-dev-bounces+stevec=futuresoft.com at mindrot.org [mailto:openssh-unix-dev-bounces+stevec=futuresoft.com at mindrot.org]On Behalf Of Cooper, Steve Sent: Friday, April 20, 2007 3:40 PM To: openssh-unix-dev at mindrot.org Subject: Cannot receive more that ~64k from host? Hi All, I have "converted" the openssh code into a Windows DLL and everything "works" up until around 64k of data packets is received from the host. What I see from extensive debugging is that select() never reports that there is more data to read. I was hoping s...

...quickly. This means I am priming the pump by downloading the first chunk of many files that are likely to be started soon. I was trying to maximize the number of files that could be primed, while keeping the download size as small as I could. Having seking enabled meant I needed to prime an extra 64K for each file, which may end up doubling or tripling the priming size. I think I will work around this by playing the .opus file with seeking disabled, then in the case where the user triggers a seek operation, closing and reopening the stream with seeking enabled. If the file is open for very...

On 07/26/2013 08:10 AM, Matt Fleming wrote: > On Wed, 24 Jul, at 08:05:16AM, Raphael S.Carvalho wrote: >> Check if ldlinux.sys is larger than 64k at build time. >> >> Signed-off-by: Raphael S.Carvalho <raphael.scarv at gmail.com> >> --- >> core/Makefile | 5 +++-- >> core/ldlinux_limit.pl | 31 +++++++++++++++++++++++++++++++ >> 2 files changed, 34 insertions(+), 2 deletions(-) >>...

This is with 64k page size. Ilia Mirkin schreef op 2020-06-22 19:27: > I suspect screen tearing (as it's usually defined) is to be expected. > Can you take a photo of what you're seeing, since I'm suspecting it's > more than regular screen tearing? > > On Mon, Jun 22, 2020 at 12:0...

...;ve figured out potential cause of the problem. The next > question how to minimize the size of ldlinux.sys? > > BTW looking at official (?) binary > https://www.kernel.org/pub/linux/utils/boot/syslinux/Testing/6.03/syslinux-6.03-pre11.tar.xz > I see that their size is also more than 64K Actually, there is *no* 64KiB limit on btrfs. Look at btrfs-progs (ctree.h:830): " /* * We don't want to overwrite 1M at the beginning of device, even though * there is our 1st superblock at 64k. Some possible reasons: * - the first 64k blank is useful for some boot loader/manager *...

In the recent commit 3842a080 to add SEND_MORE support, I blindly implemented the tls code as: if (SEND_MORE) { cork send } else { send uncork } because it showed improvements for my test case of aio-parallel-load from libnbd. But that test sticks to 64k I/O requests. But with further investigation, I've learned that even though gnutls corking works great for smaller NBD_CMD_READ replies, it can actually pessimize behavior for larger requests (such as a client sending lots of 2M read requests). This is because gnutls loses time both to realloc...

...ype WB reg 2, base: 3256MB, range: 8MB, type UC reg 3, base: 3264MB, range: 64MB, type UC reg 4, base: 3328MB, range: 256MB, type UC reg 5, base: 3584MB, range: 512MB, type UC reg 6, base: 17150MB, range: 2MB, type UC reg 7, base: 17152MB, range: 256MB, type UC total RAM covered: 16310M gran_size: 64K chunk_size: 64K num_reg: 10 lose cover RAM: 126M gran_size: 64K chunk_size: 128K num_reg: 10 lose cover RAM: 126M gran_size: 64K chunk_size: 256K num_reg: 10 lose cover RAM: 126M gran_size: 64K chunk_size: 512K num_reg:...

Hi 2013/2/27 Jos? Luis Artuch <artuch at speedy.com.ar> > > At least here, with loop and preload the problem persists. > I think it's a good option to use more than one alternative, like you > have on your website: > > <source src="http://www.radiogalere.org:8080/galere.mp3" > type='audio/mpeg'> > <source

...ost 3500@192.168.1.150:1720 -- Call token is ip$localhost/29426 -- Call reference is 29426 -- DTMF Payload is [pt=101] -- Called 3500@192.168.1.150 Setting capabilities to 0x8 (alaw) Capabilities in preference order is (alaw) Allowed Codecs: Table: G.711-ALaw-64k <1> UserInput/hookflash <2> UserInput/RFC2833 <3> UserInput/dtmf <4> Set: 0: 0: G.711-ALaw-64k <1> 1: UserInput/hookflash <2> 2: UserInput/RFC2833 <3> UserInput/dtmf <4> -- Sending SETUP...

Hi Ilia, I experience screen tearing for both 64k and 4k page size. My iMac G5 has an nVidia Geforce FX 5200 Ultra GPU. Regards, Jeroen Ilia Mirkin schreef op 2020-06-22 17:25: > Which GPU do you have? The NV40 AGP board (GeForce 6800) works > particularly poorly. However as long as you go with 4k pages (and > there's no real bene...

Hi All, I have "converted" the openssh code into a Windows DLL and everything "works" up until around 64k of data packets is received from the host. What I see from extensive debugging is that select() never reports that there is more data to read. I was hoping someone could give me a clue as to what to try next??? I believe the Winsock receive buffer defaults to 64k, but the problem is not speed re...

...g | wc -l 1443 $ ls -lhs *.img 1.2G -rw-r--r--. 1 nsoffer nsoffer 6.0G Nov ?1 21:48 dst.img 1.2G -rw-r--r--. 1 nsoffer nsoffer 6.0G Nov ?1 21:46 src.img Qemu did 1443 writes instead of 213 (5.8X). Lets repeat this conversion with the -S option: $ qemu-img convert -f raw -O raw -t none -T none -S 64k src.img dst.img $ qemu-img map -f raw --output json dst.img | wc -l 213 $ ls -lhs *.img 1.2G -rw-r--r--. 1 nsoffer nsoffer 6.0G Nov ?1 21:48 dst.img 1.2G -rw-r--r--. 1 nsoffer nsoffer 6.0G Nov ?1 21:46 src.img Picking a good value for -S is not easy. Testing show that 64k is best value for this...

I don't have any guests with PAGE_SIZE > 64k but the code seems to be clearly broken in that case as PAGE_SIZE / MERGEABLE_BUFFER_ALIGN will need more than 8 bit and so the code in mergeable_ctx_to_buf_address does not give us the actual true size. Cc: John Fastabend <john.fastabend at gmail.com> Signed-off-by: Michael S. Tsirkin <m...

I don't have any guests with PAGE_SIZE > 64k but the code seems to be clearly broken in that case as PAGE_SIZE / MERGEABLE_BUFFER_ALIGN will need more than 8 bit and so the code in mergeable_ctx_to_buf_address does not give us the actual true size. Cc: John Fastabend <john.fastabend at gmail.com> Signed-off-by: Michael S. Tsirkin <m...