I cannot find the maximum size of the symbol data type in KDB+.
Does anyone know what it is?
If youa re talking the physical length of a symbol, well symbols exist as interred strings in kdb, so the maximum string length limit would apply. As strings are just a list of characters in kdb, the maximum size of a string would be the maximum length of a list. In 3.x this would be 264 - 1, In previous versions of kdb this limit was 2,000,000,000.
However there is a 2TB maximum serialized size limit that would likely kick in first, you can roughly work out the size of a sym by serializing it,
q)count -8!`
10
q)count -8!`a
11
q)count -8!`abc
13
So each character adds a single byte, this would give a roughly 1012 character length size limit
If you mean the maximum amount of symbols that can exist in memory, then the limit is 1.4B.
Related
Suppose that we have a cpu with cache that consists of 128 blocks. 8 bytes of memory can be saved to each block.How can I find which block each address belongs to? Also what is each address' tag?
The following is my way of thinking.
Take the 32bit address 1030 for example. If I do 1030 * 4 = 4120 I have the address in a byte format. Then I turn it in a 8byte format 4120 / 8 = 515.
Then I do 515 % 128 = 3 which is (8byte address)%(number of blocks) to find the block that this address is on (block no.3).
Then I do 515 / 128 = 4 to find the possition that the address is on block no.3. So tag = 4.
Is my way of thinking correct?
Any comment is welcomed!
What we know generically:
A cache decomposes addresses into fields, namely: a tag field, an index field, and a block offset field. For any given cache the field sizes are fixed, and, knowing their width (number of bits) allows us decompose an address the same way that cache does.
An address as a simple number:
+---------------------------+
| address |
+---------------------------+
We would view addresses as unsigned integers, and the number of bits used for the address is the address space size. As decomposed into fields by the cache:
+----------------------------+
| tag | index | offset |
+----------------------------+
Each field uses an integer number of bits for its width.
What we know from your problem statement:
the block size is 8 bytes, therefore
the block offset field width is log2( block size in bytes )
the address space (total number of bit in an address) is 32 bits, therefore
tag width + index width + offset width = 32
Since information about associativity is not given we should assume the cache is direct mapped. No information to the contrary is provided, and direct mapped caches are common early in coursework. I'd verify or else state the assumption explicitly of direct mapped cache.
there are 128 blocks, therefore, for a direct mapped cache
there are 128 index positions in the cache array.
(for 2- way or 4- way we would divide by 2 or 4, respectively)
Given 128 index positions in the cache array
the index field width is log2( number of index positions )
Knowing the index field width, the block offset field width, and total address width, we can compute the tag field width
tag field width = 32 - index field width - block offset field width
Only when you have such field widths does it make sense to attempt to decode a given address and extract the fields' actual values for that address.
Because there are three fields, the preferred approach to extraction is to simply write out the address in binary and group the bits according to the fields and their widths.
(Division and modulus can be made to work but with (a) 3 fields, and (b) the index field being in the middle using math there is a arguable more complex, since to get the index we have to divide (to remove the block offset) and modulus (to remove the tag bits), but this is equivalent to the other approach.)
Comments on your reasoning:
You need to know if 1030 is in decimal or hex. It is unusual to write an addresses in decimal notation, since hex notation converts into binary notation (and hence the various bit fields) so much easier. (Some educational computers use decimal notation for addresses, but they generally have a much smaller address space, like 3 decimal digits, and certainly not a 32-bit address space.)
Take the 32bit address 1030 for example. If I do 1030 * 4 = 4120 I have the address in a byte format.
Unless something is really out of the ordinary, the address 1030 is already in byte format — so don't do that.
Then I turn it in a 8byte format 4120 / 8 = 515.
The 8 bytes of the cache make up the block offset field for decoding an address. Need to decode the address into 3 fields, not necessarily divide it.
Again the key is to first compute the block size, then the index size, then the tag size. Take a given address, convert to binary, and group the bits to know the tag, index, and block offset values in binary (then maybe convert those values to hex (or decimal if you must)).
I am testing G Suite Add On and for this purpose, I need to know maximum character limit of Property value.
As the documentation here says, quota limit for property value size is 9 KB. As the size of char vary in different language, what value of char size shall I take to calculate character limit here.
You can estimate that 1 KB is around 1024 characters.
This means that 9 KB corrsponds to around 9216 characters.
WinDbg has a range limit applied for the d-command series. According to the documentation, the limit is at 256 MB. This limit can be bypassed using the L? syntax.
L? Size (with a question mark) means the same as LSize, except that L?
Size removes the debugger's automatic range limit. Typically, there is
a range limit of 256 MB, because larger ranges are typographic errors.
If you want to specify a range that is larger than 256 MB, you must
use the L? Size syntax.
However, I tried to do a
du 3ddabac0+8 L 0n6518040
which is only 6.5 MB and it says
Range error in 'du 3ddabac0+8 l 0n6518040.
The real limit in WinDbg 6.3 is 512kB. Starting from 0x80001 or 0n524289 you need to use L? to bypass the limit.
When hashing a string, like a password, with SHA-256, is there a limit to the length of the string I am hashing? For example, is it only "safe" to hash strings that are smaller than 64 characters?
There is technically a limit, but it's quite large. The padding scheme used for SHA-256 requires that the size of the input (in bits) be expressed as a 64-bit number. Therefore, the maximum size is (264-1)/8 bytes ~= 2'091'752 terabytes.
That renders the limit almost entirely theoretical, not practical.
Most people don't have the storage for nearly that much data anyway, but even if they did, processing it all serially to produce a single hash would take an amount of time most would consider prohibitive.
A quick back-of-the-envelope kind of calculation indicates that even with the fastest enterprise SSDs currently1 listed on Tom's hardware, and striping them 16 wide to improve bandwidth, just reading that quantity of data would still take about 220 years.
1. As of April 2016.
There is no such limit, other than the maximum message size of 264-1 bits. SHA2 is frequently used to generate hashes for executables, which tend to be much larger than a few dozen bytes.
The upper limit is given in the NIST Standard FIPS 180-4. The reason for the upper limit is the padding scheme to countermeasure against the MOV attack that Merkle-Damgard construction's artifact. The message length l is lastly appended to the message during padding.
Then append the 64-bit block that is equal to the number l expressed using a binary representation
Therefore by the NIST standard, the maximum file size can be hashed with SHA-256 is 2^64-1 in bits ( approx 2.305 exabytes - that is close to the lower range of the estimated NSA's data center in UTAH, so you don't need to worry).
NIST enables the hash of the size zero message. Therefore the message length starts from 0 to 2^64-1.
If you need to hash files larger than 2^64-1 then either use SHA-512 which has 2^128-1 limit or use SHA3 which has no limit.
The Modbus/TCP packet includes the length section, which is the length of the total Modbus/TCP data minus 6 bytes. How do you figure out the length of the total Modbus/TCP data?
https://www.scadaforce.com/modbus
Length - the length of the total Modbus/TCP data minus 6 bytes
How do you figure out the length of the total Modbus/TCP data?
You must read this field then subtract '6' from the value. That result is the "length of the total Modbus/TCP data."
So, in order to implement this (a modbus-receiver) in C/C++ for example, you need to implement some manner of "framing" loop where you read a fixed-length modbus header, then you read the length specified in the header into memory.